СУХИЕ действия ASP.NET MVC: ApplicationController или Service?

Question

Я пишу приложение ASP.NET MVC 3 и довольно часто пишу эту строку в моих методах действий:

var user = _session.Single<User>(u => u.UserName == User.Identity.Name);

(очевидно, используется в сочетании с AuthorizeAttribute)

Существуют и другие вещи, которые повторяются довольно часто, но этот является наиболее заметным, и в итоге у меня есть 3 действия рядом друг с другом, каждое из которых должно найти авторизованного пользователя.

Так что этотребуется СУШКА:

1. Должен ли я написать ApplicationContoller, от которого наследуются все другие контроллеры, и выставить там свойство User, или я должен добавить это к своему IAdminServiceвыставить это как метод?

2. Является ли ApplicationController чем-то, чего следует избегать или использовать в ASP.NET MVC?

Answer 1

Если вы обнаружите, что повторяете эту логику, то может помочь пользовательский механизм связывания для типа «Пользователь»:

public class UserModelBinder : DefaultModelBinder
{
    private readonly ISession _session;
    public UserModelBinder(ISession session)
    {
        _session = session;
    }

    public override object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)
    {
        var username = controllerContext.HttpContext.User.Identity.Name;
        return _session.Single<User>(u => u.UserName == username);
    }
}

, и после регистрации связывателя действие вашего контроллера может выглядеть следующим образом:

[Authorize]
public ActionResult Foo(User user)
{
    // ...
}

Answer 2

Как человек, который не любит супер-типы контроллеров, я бы подумал об использовании Dependency Injection и использовании конструктора для «инъекции» пользователя.

o / c, у этого есть некоторые недостатки. Это означает, что вам придется использовать поле для каждого использования в вашем контроллере, а также создавать привязку в инструменте IOC. Это также предполагает, что вы используете контейнер IOC.

По поводу других опций:

Предоставление его в IAdminService дает вам дополнительное преимущество, будучи доступным в других местах, а не только в Контроллере. Так что это плюс. Просто убедитесь, что вы не перегружаете свой интерфейс слишком сильно.

Использование его в базовом контроллере поначалу также заманчиво, но я обнаружил, что базовые типы контроллеров раздуваются и неправильно управляются по мере того, как добавляется все больше и больше функциональности, потому что нет множественного наследования, и людям нужно кое-что из этого и некоторые что ... Вещи могут стать ужасными. Не говоря уже о том, что если вы используете AsyncController, у вас будет два базовых типа для управления.

По сути, между вашими двумя вариантами я бы использовал интерфейс.

Независимо от того, что вы делаете, вы все равно можете добавить метод к интерфейсу и также абстрагировать его за свойством User в базовом контроллере.