Обращение задачи построения объектов управления доменом

Question

Как я понимаю, IoC-контейнер полезен при создании объектов уровня приложений, таких как сервисы и фабрики. Но объекты уровня домена должны быть созданы вручную. Руководство Spring говорит нам: «Обычно никто не настраивает детализированные доменные объекты в контейнере, потому что DAO и бизнес-логика обычно отвечают за создание / загрузку доменных объектов».

Хорошо. Но что, если мой «мелкозернистый» объект моего домена зависит от какого-либо объекта уровня приложения. Например, у меня есть класс UserViewer (пользовательский пользователь, константы UserConstants). Там пользователь является доменным объектом, который не может быть внедрен, но UserViewer также нуждается в UserConstants, который является высокоуровневым объектом, внедренным IoC-контейнером.

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

Что не так с дизайном?

Заранее спасибо!

UPDATE

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

создать экземпляр класса UserViewer (пользователь-пользователь, служба UserService) , где пользователь передается в качестве параметра, а служба вводится из IoC.

Если я добавлю UserViewer viewer , то как мне передать user в него?

Если я создаю UserViewer Viewer вручную, то как мне передать service в него?

Answer 1

нет ничего плохого в этом дизайне. вы используете Factories для того, у кого одна ветка в домене, а другая в инфраструктуре.

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

Также, когда ваши доменные объекты поступают со слоя постоянства, вы можете подключить туда свой контейнер, чтобы добавить нужные им сервисы (NHibernate может сделать это).

Answer 2

Но что, если мой "мелкозернистый" объект моего домена зависит от какого-либо объекта уровня приложения?

Именно это считается плохой практикой. Я бы сказал, что проблемы могут быть:

1. Существует множество таких объектов, поэтому могут возникнуть проблемы с производительностью и памятью.

2. Стиль POJO заключается в том, что они могут использоваться во всех средах (сохраняются в базе данных, обрабатываются в бизнес-алгоритмах и правилах, считываются и устанавливаются в технологии просмотра, сериализуются и отправляются по сети). Внедрение в них объектов уровня приложения может вызвать следующие проблемы:

   1. В вашей архитектуре, вероятно, существует правило, согласно которому некоторые (большинство) объектов уровня приложения могут использоваться в одних слоях, а не в других. Поскольку все слои имеют доступ к pojos, правило будет нарушаться транзитивно.
   2. При сериализации и перестройке в другой JVM, что будет означать ваши объекты уровня приложения. Они бесполезны, их нужно заменить на локальные эквиваленты ...

---

Как правило, pojos, составляющие ваш домен, являются автономными. Они могут иметь доступ к другим pojos (и множеству перечислений), вот и все.

В дополнение к данным, у них есть методы, которые реализуют детали бизнес-правил или алгоритмов ( помнят идею ОО по группированию данных и кода, который работает на них; -) ):

• Это особенно хорошо, когда у них есть наследование, поскольку это позволяет настроить бизнес-правило для некоторого pojo, предоставляя другую реализацию ( другой регистр без if или switch: помните OO?; -) ).
• Любой код, который требует доступа к объектам уровня приложения (например, доступ к базе данных), удаляется, например, для службы или менеджера. Но этот код остается на высоком уровне, таким образом читаемым и простым, потому что сами pojos заботятся о деталях низкого уровня (и особых случаях).

  После этого вы часто обнаруживаете, что методы pojo многократно используются и по-разному составляются службами или менеджерами. Это большая победа в сокращении дублирования, имена методов обеспечивают столь необходимое «значение» и предоставляют более легкий доступ разработчикам, которые являются новыми для модуля.

Answer 3

Для вашего обновления:

создать экземпляр класса UserViewer (Пользователь-пользователь, служба UserService), где пользователь передается, когда параметр и служба вводятся из IoC.

Если я внедряю UserViewer Viewer, то как мне передать пользователя в него?

Если я создаю UserViewer Viewer вручную, то как мне передать ему службу?

В этом случае вам нужен фабричный метод (возможно, на вашей фабрике или локаторе). Это может выглядеть следующим образом, разделяя две части:

public UserViewer createUserViewer(User user) {
   UserViewer viewer = instantiateBean(UserViewer.class); 
   viewer.setUser(user);
   return viewer;
}

private <E> E instantiateBean(Class<E> clazz) {
   // call the IoC container to create and inject a bean
}