На каком уровне я должен применять внедрение зависимости?Контроллер или Домен?

Question

Привет, ребята, я хотел бы услышать от вас, каковы основные преимущества и недостатки применения внедрения зависимостей на уровне controller и / или domain level.

Позвольте мне объяснить; если я получу IUserRepository в качестве параметра для моего пользователя , я могу действовать двумя способами:

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

2) Я внедряю IUserRepository на свой контроллер (скажем, Register.aspx.cs), и там я создаю все свои доменные объекты, используя зависимости, которые пришли из контейнера DI .

---

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

Я с большей вероятностью использовал доменный подход (1), так как вижу значительную экономию на повторяющихся строках кода на уровне контроллера (конечно, в XML-файле будет больше строк).

Еще один момент, который поднял мой друг Роуз, заключался в том, что по какой-то причине вы обязаны перейти с контейнера di на A и сказать, что B не поддерживает инъекцию конструктора (как в случае контейнера со швом , Java, которая манипулирует BC или выполняет свою задачу только посредством внедрения сеттера), хорошо, его смысл в том, что, если у меня весь мой код на уровне контроллера, я могу плавно реорганизовать свой код, как я получаю доступ к таким инструментам, как авторефакторинг и автозаполнение, которые недоступны при работе с файлами XML.

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

Какой подход я должен использовать мою архитектуру? Есть ли другие способы мышления ???

Вы, ребята, действительно думаете, что это актуальная проблема, стоит ли беспокоиться об этом?

Answer 1

Если вы хотите избегать анемичной доменной модели , вам придется отказаться от классической n-уровневой, n-слойной архитектуры приложений CRUDY.Грег Янг объясняет, почему в этот документ о DDDD .DI не собирается это менять.

CQRS будет лучшим вариантом, и DI очень хорошо вписывается в небольшие автономные компоненты, которые этот тип архитектуры имеет тенденцию производить.

Answer 2

Я не в сфере Java, но в соответствии с вашими подробностями в ваших вопросах кажется, что вы используете какую-то инфраструктуру MVC (поскольку вы имеете дело с контроллерами и доменом).Но у меня есть мнение о том, как использовать DI в архитектуре, управляемой доменом.

Во-первых, есть несколько способов сделать DDD: некоторые используют MVC в представлении, а уровень обслуживания приложений между MVC и доменом отсутствует.Другие используют MVP (или MVVM) и не имеют уровня обслуживания.НО я думаю, что некоторые люди согласятся со мной, что вы очень редко внедряете репозитории (или другие сервисы ...).Я бы порекомендовал вводить репозитории в Command (используя MVC и без сервисного уровня), Presenter (если вы используете MVP) или Application Services (если вы используете сервисный уровень).Я в основном использую прикладной уровень, где каждый сервис получает нужные репозитории в конструкторе.

Во-вторых, я бы не стал беспокоиться о переключении между контейнерами IoC.Большинство контейнерных сред сегодня поддерживают инъекцию ctor и могут автоматически разрешать параметры.Теперь я знаю, что вы Java-разработчик и MS-разработчик, но у команды MS Practices есть локатор Common Service, который может помочь вам в создании кода, который чрезвычайно не зависит от того, какую инфраструктуру контейнера вы используете.Вероятно, в сообществе Java есть что-то похожее.

Так что перейдите к варианту 2. Надеюсь, я подтолкнул вас в правильном направлении.