Заводская модель без сервисного локатора

Question

В настоящее время я пытаюсь написать фабричный класс, который не полагается на местоположение службы.

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

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

Обновлено место службы Пример:

public class ProviderFactory : IProviderFactory 
    { 
     private readonly IProviderConfigurationService _providerConfigurationService; 

     public enum SearchType 
     { 
      Foo, 
      Bar 
     } 

     public ProviderFactory(IProviderConfigurationService providerConfigurationService) 
     { 
      _providerConfigurationService = providerConfigurationService; 
     } 

     public Collection<IProvider> GetProviderInstances(SearchType searchType) 
     { 
      // Provider configuration service will read a XML/DB store to retrieve list of search providers applicable for a search type 
      var providerList = _providerConfigurationService.GetProviderList(searchType); 
      return new Collection<IProvider>(providerList.ForEach(x=> ServiceLocator.GetInstance(typeof(x))).ToList()) ; 
     } 
    } 

Каковы мои другие варианты? В настоящее время я использую Unity для DI.

Answer 1

Альтернативой передать Func<Type, object> конструктору и реализовать функцию через контейнер:

unity.RegisterInstance<Func<Type, object>>(t => unity.Resolve(t)) 

Тогда в классе:

public ProviderFactory(Func<Type, object> createFunc, IProviderConfigurationService pcs) 
{ 
    _createFunc = createFunc; 
} 

public Collection<IProvider> GetProviderInstances(SearchType searchType) 
{ 
    var providerList = _providerConfigurationService.GetProviderList(searchType); 
    return new Collection<IProvider>(providerList.Select(_createFunc).ToList()); 
} 

Answer 2

Вам не хватает абстракции.

Ваш ProviderFactory должен реализовать абстракцию IProviderFactory. Таким образом вы можете разместить этот интерфейс в базовой библиотеке своего приложения, и вы можете разместить реализацию ProviderFactory внутри своего Composition Root. Для кода, который живет внутри вашего корня композиции, нормально ссылаться на библиотеку DI, и в этом случае you're not using service location.

Answer 3

Я недавно решенной очень похожий вопрос в моем собственном коде с использованием рамки DI. Чтобы удовлетворить Dependency Inversion, фабричный конструктор должен принять интерфейс (как говорили другие ответы), но для того, чтобы заставить фреймворк вводить правильный тип, сложно, не имея массивного списка аргументов, подробно описывающих каждую возможную конкрецию.

SimpleInjector позволяет регистрировать все конкреции данной абстракции с:

Container.RegisterCollection(typeof(IProvider), new [] {typeof(TKnown).Assembly,...}); 

Ваш XML может перечислить (возможно, внешние) узлы, где определяются конкреции, и вы могли бы построить массив сборки оттуда. Тогда ваша фабрика просто должна принять их всех и выбрать один, возможно, на основе указанного вами типа поиска.

public class ProviderFactory 
{ 
    private List<IProvider> providers; 
    public ProviderFactory(IEnumerable<IProvider> providers) 
    { 
     this.providers = providers.ToList(); 
    } 

    public IProvider GetProvider(string searchType) 
    { 
     // using a switch here would open the factory to modification 
     // which would break OCP 
     var provider = providers.SingleOrDefault(concretion => concretion.GetType().Name == searchType); 

     if (provider == null) throw new Exception("No provider found of that type. Are you missing an assembly in the RegisterCollection for IProvider?"); 

     return provider; 
    } 

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