在Spring中不注入域模型是一个好主意。它节省了一些XML，无论如何，注入域模型有什么用处。Spring DI，域模型和最佳实践
对于服务和DAO，我想解耦，所以我使用DI，但域模型通常从Web到DAO流动 - 通过横向运行的垂直层。
您认为如何？是好是坏？有没有其他推荐的最佳实践来合理地使用Spring而不是添加到XML行？
我被推荐在服务层使用工厂模式，但是那样会打败DI框架背后的整个想法，不是吗？工厂模式是一个好主意，但这会导致锅炉板代码，所以它会变成锅炉板代码V XML。
任何有关在其他区域合理使用Spring的建议，欢迎提供！
那么，你不应该注入混凝土模型对象。这不是DI的意思。你可能要做的是像某人告诉你的那样为模型对象注入工厂。 这样你就可以嘲笑你现在不想测试的“重要”部分，或者你可以切换实现。
DI有意义的外部依赖性，如数据库，服务，...
使用DI“创造”模型对象是可能的，但恕我直言不好。
看到这个问题的最多的回答：
Spring and the anemic domain model
它（特别是它引用的文章）给出了一些很有趣的方式做你想做的，而不使用像AOP和Hibernate的拦截器的工厂。
这可能会让您感到困惑，您在模型对象上的含义。如果你的意思是简单的JavaBeans包含数据但没有特定的功能，那么就没有必要去模拟它们。但我不认为这是你想到的。
如果您指的是具有特定业务逻辑的对象，那么任何DI都可能有用。在这里你可以找到Guice的例子 - 这不是Spring，但仍然是DI实现：http://code.google.com/p/google-guice/。他们建议使用DI而不是工厂。一个缺点可能是你会依赖DI--除非你只注入字段。
就我个人而言，我宁愿依靠DI来撰写复杂的工厂。