Контейнеры IoC и дизайн, управляемый доменом - PullRequest
15 голосов
/ 18 ноября 2009

Я искал руководство по использованию контейнеров IoC в дизайне, управляемом доменом. Книга Эвана, к сожалению, не затрагивает эту тему. Единственное существенное руководство, которое я мог найти в Интернете, это здесь .

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

Затем он говорит, что смешивать контейнеры и фабрики IoC не имеет смысла. Это, кажется, противоречит его первому пункту. Если на самом деле доменные зависимости не должны быть разрешены контейнером IoC, как тогда они должны быть разрешены? Книга Эвана ясно указывает на фабрики как на логический выбор.

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

Ответы [ 3 ]

3 голосов
/ 18 ноября 2009

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

Фабрики для сущностей домена не должны быть в контейнере IoC, а фабрики для служб должны. По сути, вы можете ссылаться на предприятия в своих услугах. Это не очень крепкая связь.

Хорошее прочтение о IoC можно найти на Сообщение в блоге Билли МакКафферти "Инъекция зависимости 101"

0 голосов
/ 18 ноября 2009

Мы используем DDD и внедрение зависимостей (шаблон), но не используем инфраструктуру внедрения зависимостей.

Одна проблема с популярными структурами внедрения зависимостей заключается в том, как они разделяют конфигурацию на файлы XML. XML - отличный язык разметки. Как это стало языком конфигурации, я никогда не пойму. Проблема, конечно, в том, что вам нужно запустить приложение, прежде чем вы узнаете, правильно ли все установлено. Также трудно понять, какой код используется где. Если вы используете интерфейсы, то единственной ссылкой на реализацию будет XML-файл, который сложнее обнаружить. И, наконец, вы теряете безопасность типов и дженерики. (Однажды я увидел ужасную ошибку в работе, которая была бы обнаружена компилятором, если бы мы не использовали XML.)

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

В моих последних двух проектах мы удалили большое количество «кода» из файлов XML на фабрики. Заводы подключены к службам, управляемым контейнерами (например, соединения JDBC, соединения JMS и т. Д.). Приложение стало намного проще для понимания, потому что фабрика менее многословна, чем XML. И как программисту на Java гораздо проще связать воедино программу, используя пространство элементов управления, а не перемешивание XML - и ваша IDE будет выделяться, когда вы что-то сломали.

В интеграционном тесте просто создайте объекты, как на фабрике.

е

dbConnection = DatabaseConnectionFactory.connection();    
serviceUnderTest = new PaymentProcessor(new CustomerRepository(connection));
0 голосов
/ 18 ноября 2009

Контейнеры IOC неоценимы при разработке кода, проверяемого модулем, и ортогональны DDD. Вы можете создать собственную реализацию шаблонов фабрики и сборки, если хотите ... зачем переживать неприятности?

Абсолютно. Используйте контейнер IOC, достаточно мощный, чтобы удовлетворить ваши специфические требования; не больше, не меньше.

...