it-swarm.com.ru

Как избежать безумия конструктора Dependency Injection?

Я обнаружил, что мои конструкторы начинают выглядеть так:

public MyClass(Container con, SomeClass1 obj1, SomeClass2, obj2.... )

с постоянно увеличивающимся списком параметров. Поскольку «Контейнер» является моим контейнером внедрения зависимостей, почему я не могу просто сделать это:

public MyClass(Container con)

для каждого класса? Каковы недостатки? Если я делаю это, я чувствую, что использую прославленную статику. Пожалуйста, поделитесь своими мыслями о безумии IoC и Dependency Injection.

265
JP Richardson

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

Одним из замечательных преимуществ Constructor Injection является то, что он делает нарушения принципа единой ответственности очевидно очевидными.

Когда это произойдет, пришло время рефакторинг в Facade Services . Короче говоря, создайте новый, более грубый интерфейс, который скрывает взаимодействие между некоторыми или всеми детальными зависимостями, которые вам требуются в настоящее время.

363
Mark Seemann

Я не думаю, что ваши конструкторы классов должны иметь ссылку на ваш период контейнера IOC. Это представляет ненужную зависимость между вашим классом и контейнером (тип зависимости IOC пытается избежать!). 

57
derivation

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

Внедрение зависимостей может служить ранним предупреждением для классов, становящихся слишком большими, особенно из-за возрастающей боли при переходе во все зависимости.

24
kyoryu

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

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

Подробный код с объяснением можно найти здесь

Лучшие практики для IoC на уровне сложных сервисов

3
samsur

Проблема:  

1) Конструктор с постоянно увеличивающимся списком параметров.

2) Если класс наследуется (например, RepositoryBase), то изменение конструктора Signature вызывает изменение в производных классах.

Решение 1

Передайте IoC Container конструктору 

Зачем

  • Больше не нужно постоянно увеличивать список параметров
  • Подпись конструктора становится простой

Почему бы и нет

  • Делает ваш класс тесно связанным с контейнером IoC. (Это вызывает проблемы, когда 1. вы хотите использовать этот класс в других проектах, где вы используете другой контейнер IoC. 2. вы решили изменить контейнер IoC)
  • Делает ваш класс менее описательным. (Вы не можете реально взглянуть на конструктор класса и сказать, что ему нужно для работы.)
  • Класс может получить доступ ко всем услугам.

Решение 2

Создайте класс, который группирует весь сервис и передайте его конструктору

 public abstract class EFRepositoryBase 
 {
    public class Dependency
    {
        public DbContext DbContext { get; }
        public IAuditFactory AuditFactory { get; }

         public Dependency(
            DbContext dbContext,
            IAuditFactory auditFactory)
        {
            DbContext = dbContext;
            AuditFactory = auditFactory;
        }
    }

    protected readonly DbContext DbContext;        
    protected readonly IJobariaAuditFactory auditFactory;

    protected EFRepositoryBase(Dependency dependency)
    {
        DbContext = dependency.DbContext;
        auditFactory= dependency.JobariaAuditFactory;
    }
  }

Производный класс 

  public class ApplicationEfRepository : EFRepositoryBase      
  {
     public new class Dependency : EFRepositoryBase.Dependency
     {
         public IConcreteDependency ConcreteDependency { get; }

         public Dependency(
            DbContext dbContext,
            IAuditFactory auditFactory,
            IConcreteDependency concreteDependency)
        {
            DbContext = dbContext;
            AuditFactory = auditFactory;
            ConcreteDependency = concreteDependency;
        }
     }

      IConcreteDependency _concreteDependency;

      public ApplicationEfRepository(
          Dependency dependency)
          : base(dependency)
      { 
        _concreteDependency = dependency.ConcreteDependency;
      }
   }

Зачем

  • Добавление новой зависимости к классу не влияет на производные классы 
  • Класс агностик IoC Контейнер
  • Класс описательный (в аспекте его зависимостей). По соглашению, если вы хотите узнать, от какого класса A зависит, эта информация накапливается в A.Dependency
  • Подпись конструктора становится простой

Почему бы и нет

  • нужно создать дополнительный класс
  • регистрация услуги становится сложной (Вам необходимо регистрировать каждый X.Dependency отдельно)
  • Концептуально так же, как передача IoC Container
  • .. 

Решение 2 является просто необработанным, хотя, если есть веские аргументы против него, то приветствуется описательный комментарий

1
tchelidze

Внедрение контейнера - это быстрый путь, о котором вы в конечном итоге пожалеете.

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

Вот неполный список вещей, которые нужно посмотреть

Плохой дизайн домена (агрегирование корневых файлов… и т.д.)

Плохое разделение интересов (состав службы, команды, запросы). См. CQRS и Sourcing Event.

ИЛИ Mappers (будьте осторожны, эти вещи могут привести к неприятностям)

Просмотр моделей и других DTO (никогда не используйте повторно и старайтесь свести их к минимуму !!!!)

0
Marius

Я прочитал всю эту ветку дважды, и думаю, что люди отвечают тем, что они знают, а не тем, что спрашивают.

Исходный вопрос JP выглядит так, будто он строит объекты, отправляя распознаватель, а затем группу классов, но мы предполагаем, что эти классы/объекты сами по себе являются сервисами, готовыми для внедрения. Что делать, если они не?

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

Container.GetSevice<MyClass>(someObject1, someObject2)

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

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

Однако существуют рамки, которые могут помочь, даже если они выглядят немного некрасиво. Например, Ninject:

Создание экземпляра с использованием Ninject с дополнительными параметрами в конструкторе

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

0
Craig Brunetti

Это подход, который я использую

public class Hero
{

    [Inject]
    private IInventory Inventory { get; set; }

    [Inject]
    private IArmour Armour { get; set; }

    [Inject]
    protected IWeapon Weapon { get; set; }

    [Inject]
    private IAction Jump { get; set; }

    [Inject]
    private IInstanceProvider InstanceProvider { get; set; }


}

Вот грубый подход к выполнению инъекций и запуску конструктора после введения значений. Это полностью функциональная программа.

public class InjectAttribute : Attribute
{

}


public class TestClass
{
    [Inject]
    private SomeDependency sd { get; set; }

    public TestClass()
    {
        Console.WriteLine("ctor");
        Console.WriteLine(sd);
    }
}

public class SomeDependency
{

}


class Program
{
    static void Main(string[] args)
    {
        object tc = FormatterServices.GetUninitializedObject(typeof(TestClass));

        // Get all properties with inject tag
        List<PropertyInfo> pi = typeof(TestClass)
            .GetProperties(BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.Public)
            .Where(info => info.GetCustomAttributes(typeof(InjectAttribute), false).Length > 0).ToList();

        // We now happen to know there's only one dependency so we take a shortcut just for the sake of this example and just set value to it without inspecting it
        pi[0].SetValue(tc, new SomeDependency(), null);


        // Find the right constructor and Invoke it. 
        ConstructorInfo ci = typeof(TestClass).GetConstructors()[0];
        ci.Invoke(tc, null);

    }
}

В настоящее время я работаю над проектом хобби, который работает следующим образом https://github.com/Jokine/ToolProject/tree/Core

0
Ronijo