IFilterProvider и разделение проблем

Ответ 1

Да, я думаю, вы поняли, что правильно. Мне нравится, что вы разделяете проблемы между атрибутом и реализацией фильтра, и мне нравится, что вы используете конструктор DI, а не свойство DI.

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

Если вы хотите совместить атрибут с фильтром и использовать свойство DI, есть простой способ иметь более развязанного поставщика фильтра. Вот два примера такого подхода: http://www.thecodinghumanist.com/blog/archives/2011/1/27/structuremap-action-filters-and-dependency-injection-in-asp-net-mvc-3 http://lozanotek.com/blog/archive/2010/10/12/dependency_injection_for_filters_in_mvc3.aspx

С текущим подходом можно решить две проблемы: 1. Ввод некоторых, но не всех, параметров конструктора фильтра через DI. 2. Сопоставление атрибута с экземпляром фильтра (вложенным в зависимость).

В настоящее время вы делаете оба вручную, что, безусловно, прекрасно, когда есть только один фильтр/атрибут. Если бы было больше, вам, вероятно, понадобился бы более общий подход для обеих частей.

Для вызова # 1 вы можете использовать что-то вроде перегрузки _container.Resolve, которая позволяет передавать аргументы. Это решение скорее специфично для контейнеров и, вероятно, немного сложнее.

Другое решение, которое я опишу здесь, отделяет класс factory, который принимает только зависимости в своем конструкторе и создает экземпляр фильтра, требующий как аргументов DI, так и не DI.

Вот что может выглядеть factory:

public interface IFilterInstanceFactory
{
    object Create(Attribute attribute);
}

Затем вы создадите factory для каждой пары атрибут/фильтр:

public class MyAuthorizationFilterFactory : IFilterInstanceFactory
{
    private readonly IAuthorizationProvider provider;

    public MyAuthorizationFilterFactory(IAuthorizationProvider provider)
    {
        this.provider = provider;
    }

    public object Create(Attribute attribute)
    {
        MyAuthorizeAttribute authorizeAttribute = attribute as MyAuthorizeAttribute;

        if (authorizeAttribute == null)
        {
            return null;
        }

        return new MyAuthorizationFilter(provider, authorizeAttribute.Code);
   }
}

Вы можете решить задачу № 2, просто зарегистрировав каждую реализацию IFilterInstanceFactory с помощью CastleWindsor.

Поставщик фильтра теперь может быть отделен от любого знания определенных атрибутов и фильтров:

public class MyFilterProvider : IFilterProvider
{
    private IWindsorContainer _container;

    public MyFilterProvider(IWindsorContainer container)
    {
        Contract.Requires(container != null);
        _container = container;
    }

    public IEnumerable<Filter> GetFilters(ControllerContext controllerContext, ActionDescriptor actionDescriptor)
    {
        Type controllerType = controllerContext.Controller.GetType();
        var authorizationProvider = _container.Resolve<IAuthorizationProvider>();
        foreach (FilterAttribute attribute in controllerType.GetCustomAttributes(typeof(FilterAttribute), false))
        {
            object instance = Resolve(attribute);
            yield return new Filter(instance, FilterScope.Controller, 0);
        }
        foreach (FilterAttribute attribute in actionDescriptor.GetCustomAttributes(typeof(FilterAttribute), false))
        {
            object instance = Resolve(attribute);
            yield return new Filter(instance, FilterScope.Action, 0);
        }
    }

    private object Resolve(Attribute attribute)
    {
        IFilterInstanceFactory[] factories = _container.ResolveAll<IFilterInstanceFactory>();

        foreach (IFilterInstanceFactory factory in factories)
        {
            object dependencyInjectedInstance = factory.Create(attribute);

            if (dependencyInjectedInstance != null)
            {
                return dependencyInjectedInstance;
            }
        }

        return attribute;
    }
}

Дэвид

Ответ 2

Это, вероятно, немного, но один из способов избежать factory, предложенный Дэвидом (и сделать это немного более общим), - это ввести еще один атрибут.

[AssociatedFilter(typeof(MyAuthorizationFilter))]

Что вы можете добавить к исходному атрибуту следующим образом.

[AssociatedFilter(typeof(MyAuthorizationFilter))]
[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method)]
public class MyAuthorizeAttribute : Attribute
{
    public string Code { get; set; }
}

Атрибут AssociatedFilter выглядит следующим образом.

public class AssociatedFilterAttribute : Attribute
{
    public AssociatedFilterAttribute(Type filterType)
    {
        FilterType = filterType;
    }
    public Type FilterType { get; set; }
}

Затем вы можете получить правильный фильтр, вытащив FilterType из этого атрибута.

private object Resolve(Attribute attribute)
{
    var filterAttributes = attribute.GetType().GetCustomAttributes(typeof(AssociatedFilterAttribute), false);
    var first = (AssociatedFilterAttribute)filterAttributes.FirstOrDefault();
    return new Filter(_container.Resolve(first.FilterType), FilterScope.First, null); 
}

В настоящее время это ограничивается только принятием первого атрибута AssociatedFilter, теоретически, я думаю, вы могли бы добавить несколько (один атрибут запускает несколько фильтров), и в этом случае вы бы опустили бит, где это захватывает первый результат.

Очевидно, нам также необходимо добавить обработку ошибок, например. если нет атрибута AssociatedFilterAttribute...