Весна DI, модель домена и лучшие практики

Question

Не рекомендуется ли вводить модели домена весной. Это экономит некоторый XML, и в любом случае использование инъекционной модели домена.

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

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

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

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

Answer 1

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

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

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

Answer 2

См верхний ответ на этот вопрос в:

Spring and the anemic domain model

Это (и особенно в статье он приводит) дает некоторые очень интересные способы, чтобы сделать то, что вы хотите без завода, используя такие вещи, как АОП или гибернации перехватчики.

Answer 3

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

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

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