2010-03-09 6 views
2

Использование Unity в приложении ASP.Net MVC 2 У меня есть различные зависимости от экземпляров, созданных правильно. Тем не менее, я хочу, чтобы убедиться, что ток IPrincipal для пользователя будет передаваться через инъекции для снижения уровня обслуживания, Repository и т.д.Внедрение IPrincipal с внедрением свойств Unity во время выполнения

Поэтому в более низком уровне сервиса у меня есть что-то вроде:

[Dependency] IPrincipal CurrentUser {get; set;} 

Если я использую Injection Dependency Injection, я не получаю то, что хочу, потому что контроллер создан ранее, чем доступен пользовательский принцип, и в любом случае Unity не знает, чтобы получить текущие учетные данные пользователя.

Так что я хочу, чтобы вставлять IPrincipal текущего пользователя (или, возможно, RolePrincipal) в одну из зависимостей для контроллера.

Как я могу это сделать?

+1

Спасибо за mrjoltcola ответов и mnemosyn. Я согласен с комментариями об инъекции зависимостей. Идея, над которой я работаю, заключается в том, чтобы она автоматически присутствовала в сервисе и репозитории, чтобы не добавлять дополнительный код в класс контроллера каждый раз, когда разработчик собирается обновить базу данных. Поскольку это связано с аудитом, я хочу, чтобы пользователь времени выполнения всегда был доступен и что разработчику не нужно помнить о его прохождении. – Redeemed1

ответ

7

Почему бы не воспользоваться прямым маршрутом и просто назначить его.

Thread.CurrentPrincipal = пользователь;

Инъекционная инъекция хороша, но не позволяйте ей мешать лучшему инжектору зависимости, программисту.

+0

+1 Thread.CurrentPrincipal уже является стандартом де-факто для работы с текущим пользователем, и редко есть причины отклоняться от этой хорошо установленной идиумы кодирования. –

+0

Приложение является многоуровневым и, скорее всего, будет развернуто в несколько уровней, так что у меня есть приложение CustomPrincipal, которое может быть передано во избежание любого загрязнения срединных/back-end уровней с помощью зависимостей HttpContext. Предполагая, что связь WCF с веб-презентацией (MVC Controller) будет использоваться для служб среднего уровня, могу ли я быть уверенным, что Thread.CurrentPrincipal вернет IPRincipal с проверкой подлинности WebForms? – Redeemed1

0

Зачем вводить его? Текущий директор уже присутствует как User. Это то, что мы используем, и пока оно прекрасно работает. Пользователь не должен меняться в рамках одного запроса, не так ли?

protected void Application_AuthenticateRequest() 
{ 
    var ticket = GetAuthenticationTicket(); 
    // Perform actual authentication, etc. 
    MyUser user = BigAuthStuff(); 
    Context.User = user; 
    Thread.CurrentPrincipal = user; 
} 

public class MyBaseController : Controller 
{ 
    protected MyUser AuthenticatedUser 
    { 
     get { return User as MyUser; } 
    } 
} 
+1

Context.User работает не очень хорошо, если веб-сайт вызывает технологию Domain-Agnostic Domain Model. Было бы серьезной ошибкой для модели домена, чтобы попытаться получить доступ к любому виду HTTP-контекста. –

+0

Хм, действительно. Тем не менее, я не думаю, что модель домена должна взаимодействовать с каким-то статическим внешним. Идея состоит в том, чтобы поместить пользователя в контекст, чтобы контроллер мог работать с ним. В конечном счете, это должен быть контроллер, который звонит в модель домена, верно? Возможно, вы могли бы пойти еще дальше и сказать: у модели домена не должно быть понятия о пользователях, выполняющих код вообще. Если модель домена связана с авторизацией, она должна включать только эту функциональность, поэтому нам нужно настроить модель домена на основе текущего пользователя, которую мы снова должны делать в контроллере ?! – mnemosyn

+0

проблема проходит учетные данные полностью через многоуровневое развертывание через wcf и приносит некоторые другие атрибуты (например, роли) в пользовательском принципе – Redeemed1

Смежные вопросы