我看了http://solitarygeek.com/java/developing-a-simple-java-application-with-spring/comment-page-1#comment-1639爲什麼要使用服務層？
的例子我試圖弄清楚爲什麼在他提供的例子中首先需要服務層。如果你拿出來，然後在你的客戶，你可能只是做：
UserDao userDao = new UserDaoImpl();
Iterator users = userDao.getUsers();
while (…) {
…
}
這似乎是服務層僅僅是圍繞DAO的包裝。如果服務層被刪除，有人能給我一個事情會變得混亂的情況嗎？我只是看不到服務層開始的重點。
使服務層成爲DAO的包裝是一種常見的反模式。在這個例子中，你給它肯定不是很有用。使用服務層意味着你得到幾個好處：
你做腹式活動的控制器和通用業務邏輯，是不是網絡相關的最好的做法有明顯的區別。您可以與控制器邏輯分開測試與服務相關的業務邏輯。
您可以指定事務行爲，因此如果您調用了多個數據訪問對象，則可以指定它們發生在同一個事務中。在你的例子中，有一個對dao的初始調用，後面跟着一個循環，這可能包含更多的dao調用。將這些調用保存在一個事務中，並且數據庫的工作量更少（不必爲每次調用Dao創建一個新的事務），但更重要的是，這意味着檢索到的數據將更加一致。
您可以嵌套服務，以便如果一個人有不同的事務行爲（需要自己的事務），您可以強制執行該操作。
您可以使用postCommit攔截器來執行通知內容，例如發送電子郵件，這樣不會使控制器垃圾。
通常我有包含用例用於單個類型的用戶服務，在服務中的每個方法是單個動作（工作在單個請求 - 響應週期做），該用戶將被執行，與你的例子不同，這裏通常不僅僅是一個簡單的數據訪問對象調用。
看看下面的文章：
http://www.martinfowler.com/bliki/AnemicDomainModel.html
這一切都取決於你想要把你的邏輯 - 在您的服務或您的域對象。
如果您有一個複雜的體系結構並需要與您的DAO和數據有不同的接口，那麼服務層方法是適當的。爲客戶提供調用粒度的方法也是很好的 - 這可以調用多個DAO來獲取數據。
但是，在大多數情況下，您需要的是一個簡單的體系結構，因此跳過服務層並查看域模型方法。域名由Eric Evans的驅動設計和相關的文章在這個位置展開：
使用服務層是在Java社區廣泛接受的設計模式。是的，你可以直接使用dao實現，但是如果你想要應用一些業務規則。
假設，您希望在允許用戶登錄到系統之前執行一些檢查。你會把這些邏輯放在哪裏？另外，服務層是交易劃分的地方。
保持道路層清潔和精益通常很好。我建議你閱讀文章「Don’t repeat the DAO」。如果你遵循這篇文章中的原則，你將不會爲你的daos編寫任何實現。
此外，請注意，該博客的範圍是爲了幫助初學者在春季。春天是如此強大，你可以彎曲，以滿足您的需求與像AOP等強大的概念
問候， 詹姆斯
「在這個例子中，你給它肯定不是非常有用」的今天，沒有用的。明天當你開始添加更多的功能，並且需要邏輯和規則（可能需要根據客戶/安裝等不同而不同） - 邏輯不應該放在數據訪問層中。 – nos 2010-09-11 00:24:13
@nos：同意。雖然我不願意建議人們因爲未來可能不需要而放入某些東西，但隨着應用程序的增長，這太容易了，因爲它很方便，將新的東西塞進控制器或道。 – 2011-09-29 13:13:05