Spring DI, Модель предметной области и лучшие практики

Question

Это хорошая идея, чтобы не внедрять доменные модели весной. Он сохраняет некоторый XML, и в любом случае, какая польза от внедрения модели домена.

Для сервисов и DAO я хочу отделить, поэтому я использую DI, но Domain Model обычно проходит весь путь от Web до DAO - своего рода вертикальный слой, проходящий через горизонтали.

Что ты думаешь? Хорошо или плохо? Существуют ли другие рекомендуемые рекомендации по разумному использованию Spring вместо добавления в строки XML?

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

Любые предложения по разумному использованию Spring в других областях приветствуются !!

Answer 1

Смотрите главный ответ на этот вопрос:

Spring и модель анемичной области

Он (и особенно статья, на которую он ссылается) дает некоторые действительно интересные способы сделать то, что вы хотите без фабрики, используя такие вещи, как AOP или Hibernate Interceptors.

Answer 2

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

DI имеет смысл для внешних зависимостей, таких как база данных, службы, ...

Использование DI для "создания" объектов модели возможно, но ИМХО плохо.

Answer 3

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

Если вы имеете в виду объекты с определенной бизнес-логикой, тогда любой DI может быть полезен. Здесь вы можете найти примеры с Guice - это не Spring, но все же реализация DI: http://code.google.com/p/google-guice/. Они предлагают использовать DI вместо заводов. Одним из недостатков может быть то, что вы будете зависеть от DI - если только вы не вводите только поля.

Лично я бы предпочел зависеть от DI, который написал сложные фабрики.