Как избежать безумия Dependency Injection конструктора?
Я обнаружил, что мои конструкторы начинают выглядеть так:
public MyClass(Container con, SomeClass1 obj1, SomeClass2, obj2.... )
с постоянно увеличивающимся списком параметров. Поскольку "Контейнер" является моим контейнером внедрения зависимостей, почему я не могу просто сделать это:
public MyClass(Container con)
для каждого класса? Каковы недостатки? Если я делаю это, я чувствую, что использую прославленную статику. Пожалуйста, поделитесь своими мыслями о безумии IoC и Dependency Injection.
10 ответов
Вы правы в том, что если вы используете контейнер в качестве локатора службы, это более или менее прославленная статическая фабрика. По многим причинам я считаю это анти-паттерном.
Одним из замечательных преимуществ Constructor Injection является то, что он делает нарушения принципа единой ответственности совершенно очевидными.
Когда это произойдет, пришло время провести рефакторинг в Facade Services. Короче говоря, создайте новый, более грубый интерфейс, который скрывает взаимодействие между некоторыми или всеми мелкозернистыми зависимостями, которые вам требуются в настоящее время.
Я не думаю, что ваши конструкторы классов должны иметь ссылку на ваш период контейнера IOC. Это представляет ненужную зависимость между вашим классом и контейнером (тип зависимости, которую IOC пытается избежать!).
Сложность передачи параметров не является проблемой. Проблема в том, что ваш класс делает слишком много, и его нужно больше разбивать.
Внедрение зависимостей может служить ранним предупреждением для классов, становящихся слишком большими, особенно из-за возрастающей боли при переходе во все зависимости.
Проблема:
1) Конструктор с постоянно увеличивающимся списком параметров.
2) Если класс наследуется (например: RepositoryBase) затем изменение сигнатуры конструктора вызывает изменение в производных классах.
Решение 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 просто необработанное, хотя, если есть веские аргументы против него, то желательно иметь описательный комментарий
Я прочитал всю эту ветку дважды, и я думаю, что люди отвечают тем, что они знают, а не тем, что спрашивают.
Исходный вопрос JP выглядит так, как будто он строит объекты, отправляя распознаватель, а затем группу классов, но мы предполагаем, что эти классы / объекты сами по себе являются сервисами, готовыми для внедрения. Что делать, если они не?
JP, если вы хотите использовать DI и хотите получить славу от смешения инъекций с контекстными данными, ни один из этих паттернов (или предполагаемых "анти-паттернов") специально не решает эту проблему. Это на самом деле сводится к использованию пакета, который поддержит вас в таких усилиях.
Container.GetSevice<MyClass>(someObject1, someObject2)
... этот формат редко поддерживается. Я считаю, что сложность программирования такой поддержки, добавляемая к жалкой производительности, которая может быть связана с реализацией, делает ее непривлекательной для разработчиков с открытым исходным кодом.
Но это должно быть сделано, потому что я должен иметь возможность создавать и регистрировать фабрику для MyClass'ов, и эта фабрика должна иметь возможность получать данные / ввод, которые не превращаются в "службу" только для передачи данные. Если "анти-паттерн" связан с негативными последствиями, то форсирование существования искусственных типов сервисов для передачи данных / моделей, безусловно, негативно (наравне с вашим ощущением, что вы упаковываете свои классы в контейнер. Применяется тот же инстинкт).
Однако есть рамки, которые могут помочь, даже если они выглядят немного некрасиво. Например, Ninject:
Создание экземпляра с использованием Ninject с дополнительными параметрами в конструкторе
Это для.NET, популярно, и еще нигде не так чисто, как должно быть, но я уверен, что есть что-то на любом языке, который вы выберете.
Я натолкнулся на похожий вопрос о внедрении зависимостей на основе конструктора и о том, насколько сложным было передать все зависимости.
Один из подходов, который я использовал в прошлом, заключается в использовании шаблона фасада приложения с использованием сервисного уровня. Это будет иметь грубый API. Если этот сервис зависит от репозиториев, он будет использовать установку частных свойств. Это требует создания абстрактной фабрики и перемещения логики создания хранилищ в фабрику.
Подробный код с объяснением можно найти здесь
Введение контейнера - это быстрый путь, о котором вы в конечном итоге пожалеете.
Чрезмерная инъекция не является проблемой, это, как правило, является признаком других структурных недостатков, в первую очередь разделения проблем. Это не одна проблема, но она может иметь много источников, и что делает это так трудно исправить, так это то, что вам придется иметь дело со всеми из них, иногда в одно и то же время (подумайте о спагетти без запутывания).
Вот неполный список вещей, которые нужно посмотреть
Плохой дизайн домена (агрегированные корни… и т. Д.)
Плохое разделение интересов (состав службы, команды, запросы). См. CQRS и Sourcing Event.
ИЛИ Mappers (будьте осторожны, эти вещи могут привести к неприятностям)
Просмотр моделей и других DTO (никогда не используйте повторно и старайтесь свести их к минимуму!!!!)
Это подход, который я использую
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
Слишком много параметров для метода — это намек (не обязательно), что ваш метод слишком большой/имеет слишком много ответственности.
Кроме того, параметры, которые используются в одном и том же методе (могут) иметь высокую связанность -> стоит подумать о том, чтобы поместить их в один класс -> должен передаваться только один параметр.
Какую инфраструктуру внедрения зависимостей вы используете? Вы пробовали использовать инъекцию на основе сеттера?
Преимущество внедрения на основе конструктора состоит в том, что это выглядит естественным для Java-программистов, которые не используют DI-инфраструктуры. Вам нужно 5 вещей для инициализации класса, тогда у вас есть 5 аргументов для вашего конструктора. Недостатком является то, что вы заметили, это становится громоздким, когда у вас много зависимостей.
В Spring вы можете вместо этого передавать требуемые значения с помощью сеттеров и использовать аннотации @required, чтобы обеспечить их внедрение. Недостатком является то, что вам нужно переместить код инициализации из конструктора в другой метод и вызвать Spring, который после того, как все зависимости введены, пометив его @PostConstruct. Я не уверен насчет других фреймворков, но я предполагаю, что они делают нечто подобное.
Оба способа работают, это вопрос предпочтений.