在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來撰寫複雜的工廠。