Введення залежностей у фільтри дій ASP.NET MVC 3. Що поганого в такому підході?

Ось установка. Скажімо, у мене є якийсь фільтр дій, який потребує екземпляра служби:

public interface IMyService
{
   void DoSomething();
}

public class MyService : IMyService
{
   public void DoSomething(){}
}

Потім у мене є ActionFilter, який потребує екземпляра цієї служби:

public class MyActionFilter : ActionFilterAttribute
{
   private IMyService _myService; // <--- How do we get this injected

   public override void OnActionExecuting(ActionExecutingContext filterContext)
   {
       _myService.DoSomething();
       base.OnActionExecuting(filterContext);
   }
}

У MVC 1/2 впорскування залежностей у фільтри дій було болем у дупі. Найбільш поширений підхід полягає у використанні Invoker призначених для користувача дій , як можна побачити тут: http://www.jeremyskinner.co.uk/2008/11/08/dependency-injection-with-aspnet-mvc-action-filters/ Основною мотивацією цього обхідного шляху було те, що такий наступний підхід вважався недбалим і щільним зчепленням з контейнером:

public class MyActionFilter : ActionFilterAttribute
{
   private IMyService _myService;

   public MyActionFilter()
      :this(MyStaticKernel.Get<IMyService>()) //using Ninject, but would apply to any container
   {

   }

   public MyActionFilter(IMyService myService)
   {
      _myService = myService;
   }

   public override void OnActionExecuting(ActionExecutingContext filterContext)
   {
       _myService.DoSomething();
       base.OnActionExecuting(filterContext);
   }
}

Тут ми використовуємо інжектор конструктора та перевантажуємо конструктор, щоб використовувати контейнер та вводити службу. Я погоджуюсь, що щільно поєднує контейнер із ActionFilter.

Моє запитання полягає в наступному: тепер у ASP.NET MVC 3, де ми маємо абстракцію використовуваного контейнера (через DependencyResolver), чи всі ці обручі все ще необхідні? Дозвольте мені продемонструвати:

public class MyActionFilter : ActionFilterAttribute
{
   private IMyService _myService;

   public MyActionFilter()
      :this(DependencyResolver.Current.GetService(typeof(IMyService)) as IMyService)
   {

   }

   public MyActionFilter(IMyService myService)
   {
      _myService = myService;
   }

   public override void OnActionExecuting(ActionExecutingContext filterContext)
   {
       _myService.DoSomething();
       base.OnActionExecuting(filterContext);
   }
}

Тепер я знаю, що деякі пуристи можуть знущатися з цього, але серйозно, що може бути мінусом? Це все ще можна перевірити, оскільки ви можете використовувати конструктор, який приймає IMyService під час тестування, і таким чином вводити макетну службу. Ви не прив'язані до жодної реалізації контейнера DI, оскільки використовуєте DependencyResolver, тож чи є у цього підходу мінуси?

До речі, ось ще один приємний підхід для цього в MVC3 за допомогою нового інтерфейсу IFilterProvider: http://www.thecodinghumanist.com/blog/archives/2011/1/27/structuremap-action-filters-and-dependency-injection-in -asp-net-mvc-3

Я не впевнений, але я вважаю, що ви можете просто використовувати порожній конструктор (для частини атрибута ), а потім мати конструктор, який фактично вводить значення (для частини фільтра ). *

Редагувати : Після невеликого читання виявляється, що прийнятим способом цього є введення властивостей:

public class MyActionFilter : ActionFilterAttribute
{
    [Injected]
    public IMyService MyService {get;set;}
    
    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        MyService.DoSomething();
        base.OnActionExecuting(filterContext);
    }
}

Щодо того, чому не використовувати запитання Service Locator : це здебільшого просто зменшує гнучкість введення вашої залежності. Наприклад, що робити, якщо ви вводите послугу журналювання, і ви хочете автоматично дати службі реєстрації ім'я класу, в який вона вводиться? Якщо ви використовуєте інжектор конструктора, це буде чудово працювати. Якщо ви використовуєте вирішувач залежностей / локатор послуг, вам не пощастить.

Оновлення

Оскільки це було прийнято як відповідь, я хотів би продовжити, щоб сказати, що я віддаю перевагу підходу Марка Сімана, оскільки він відокремлює відповідальність фільтра дій від атрибуту. Крім того, розширення MVC3 від Ninject має кілька дуже потужних способів налаштування фільтрів дій за допомогою прив'язок. Детальніше див. Наступні посилання:

• https://github.com/ninject/ninject.web.mvc/wiki/Dependency-injection-for-filters
• https://github.com/ninject/ninject.web.mvc/wiki/Conditional-bindings-for-filters
• https://github.com/ninject/ninject.web.mvc/wiki/Filter-configurations

Оновлення 2

Як зазначив @usr у коментарях нижче, ActionFilterAttributeекземпляри s створюються під час завантаження класу, і вони тривають протягом усього життя програми. Якщо IMyServiceінтерфейс не повинен бути одностороннім, то він в кінцевому підсумку є залежною залежністю . Якщо його реалізація не є безпечною для потоків, вам може бути багато болю.

Всякий раз, коли у вас є залежність з меншою тривалістю життя, ніж очікувана тривалість життя вашого класу, розумно вливати фабрику, щоб виготовити цю залежність на вимогу, а не вводити її безпосередньо.

Так, є і мінуси, оскільки з самим IDependencyResolver є багато проблем , і до них можна додати використання Singleton Service Locator, а також Bastard Injection .

Кращий варіант - застосувати фільтр як звичайний клас, в який ви можете вводити будь-які послуги, які хочете:

public class MyActionFilter : IActionFilter
{
    private readonly IMyService myService;

    public MyActionFilter(IMyService myService)
    {
        this.myService = myService;
    }

    public void OnActionExecuting(ActionExecutingContext filterContext)
    {
        if(this.ApplyBehavior(filterContext))
            this.myService.DoSomething();
    }

    public void OnActionExecuted(ActionExecutedContext filterContext)
    {
        if(this.ApplyBehavior(filterContext))
            this.myService.DoSomething();
    }

    private bool ApplyBehavior(ActionExecutingContext filterContext)
    {
        // Look for a marker attribute in the filterContext or use some other rule
        // to determine whether or not to apply the behavior.
    }

    private bool ApplyBehavior(ActionExecutedContext filterContext)
    {
        // Same as above
    }
}

Зверніть увагу, як фільтр перевіряє filterContext, щоб визначити, чи слід застосовувати поведінку.

Це означає, що ви все ще можете використовувати атрибути, щоб контролювати, чи слід застосовувати фільтр:

public class MyActionFilterAttribute : Attribute { }

Однак зараз цей атрибут є абсолютно інертним.

Фільтр можна скласти з необхідною залежністю та додати до глобальних фільтрів у global.asax:

GlobalFilters.Filters.Add(new MyActionFilter(new MyService()));

Детальніший приклад цієї техніки, хоча і застосовується до веб-API ASP.NET замість MVC, див. У цій статті: http://blog.ploeh.dk/2014/06/13/passive-attributes

Рішення, яке запропонував Марк Сіманн, здається елегантним. Однак досить складний для простої задачі. Використання фреймворку шляхом реалізації AuthorizeAttribute здається більш природним.

Моїм рішенням було створити AuthorizeAttribute із заводу статичних делегатів до служби, зареєстрованої в global.asax. Він працює для будь-якого контейнера DI і відчуває себе трохи краще, ніж сервер Locator.

У global.asax:

MyAuthorizeAttribute.AuthorizeServiceFactory = () => Container.Resolve<IAuthorizeService>();

Мій власний клас атрибутів:

[AttributeUsage(AttributeTargets.Method | AttributeTargets.Class)]
public class MyAuthorizeAttribute : AuthorizeAttribute
{
    public static Func<IAuthorizeService> AuthorizeServiceFactory { get; set; } 

    protected override bool AuthorizeCore(HttpContextBase httpContext)
    {
        return AuthorizeServiceFactory().AuthorizeCore(httpContext);
    }
}