Внедрение зависимостей и поставщики членства в ASP.Net

Если вы настраиваете настраиваемых поставщиков членства с помощью элемента ‹membership> в файле Web.config, я могу видеть проблемы, которые могут возникнуть при внедрении зависимостей.

Поставщики конструируются и управляются фреймворком, и у вас нет возможности перехватить эту конструкцию, чтобы обеспечить дополнительную инъекцию зависимостей для интерфейса IDataStore.

Если мое предположение верно, то вы можете переопределить метод Initialize() в вашем настраиваемом провайдере и выполнить там внедрение зависимостей. Вы можете иметь настраиваемую настройку имени / значения в конфигурации поставщика, которая указывает на тип, реализующий IDataStore, который передается как часть словаря методу Initialize().

Затем вы активируете экземпляр типа хранилища данных и устанавливаете его в соответствующем свойстве:

public class MyMembershipProvider : MembershipProvider
{
    public IDataStore DataStore
    {
        get;
        set;
    }

    public override Initialize(string name, NameValueCollection config)
    {
        var dataStoreType = config["dataStoreProvider"];
        if (!String.IsNullOrEmpty(dataStoreType))
        {
            var type = Type.GetType(dataStoreType);
            DataStore = (IDataStore) Activator.CreateInstance(type);
        }
    }
}

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

Для сценариев тестирования вы просто устанавливаете свойство хранилища данных в самом экземпляре поставщика, так как вы будете создавать его непосредственно в своих тестах.

Разве так не лучше? Я использую его с MVC3 и ninject. Достаточно добавить свойство в свой собственный класс поставщика членства. Не забудьте добавить "using System.Web.Mvc;" наверху.

public IRepository Repository
{
    get
    {
        return DependencyResolver.Current.GetService<IRepository>();
    }
}

Самый простой способ сделать инъекцию зависимостей, который я видел (и на самом деле единственный, который я использовал до сих пор ...), - это заставить конструктор вашего зависимого класса принять интерфейс в качестве параметра и назначить его частному поле. Если хотите, вы также можете добавить конструктор «по умолчанию», который будет цепляться за первый конструктор со значением по умолчанию.

В упрощенном виде это будет выглядеть примерно так:

public class DependentClass
{
    private IDataStore _store;

    // Use this constructor when you want strict control of the implementation
    public DependentClass(IDataStore store)
    {
         this._store = store;
    }

    // Use this constructor when you don't want to create an IDataStore instance
    // manually every time you create a DependentClass instance
    public DependentClass() : this(new DefaultDataStore()) { }
}

Эта концепция называется «цепочка конструкторов», и в Интернете есть много статей о том, как это сделать. Я считаю, что этот учебник очень хорошо объясняет шаблон DI.