IoC на уровне домена - PullRequest
       33

IoC на уровне домена

0 голосов
/ 28 сентября 2018

В моем доменном слое у меня есть контракт Hashing.Один из моих доменных сервисов зависит от этого договора.На данный момент я внедрил его в метод __construct.

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

Все это работает.Но я знаю, что сервисные зависимости будут расти.Я добавлю к ним гораздо больше вариантов использования .И есть еще одна проблема - контейнер внедряет все зависимости, но мы могли бы использовать только один UseCase , поэтому он будет выполнять лишнюю работу.

Это нормально, если я добавлю контейнер IoCсам вместо многих параметров, и использовать его в UseCases .

Контракт IoC также лежит в пространстве имен контрактов на уровне домена

1 Ответ

0 голосов
/ 29 сентября 2018

Это нормально, если вместо многих параметров я добавлю сам контейнер IoC

Нет, все не в порядке.Предоставление любого класса за пределами вашего Composition Root с доступом к неограниченному набору зависимостей считается анти-паттерном.Этот анти-шаблон называется Service Locator .

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

Может возникнуть соблазн добавить контейнер, чтобы предотвратить дальнейшее изменение конструктора класса, но это признак другой проблемы.Классы, которые продолжают получать новые зависимости, вероятно, нарушают Принцип единой ответственности .Вы получите классы с множеством аргументов конструктора - запах кода, называемый Чрезмерная инъекция конструктора .

...