我知道這個主題有相當多的內容，但我似乎無法找到任何完全解答我的問題的東西。我被告知使用服務 - > DAO->低級代碼架構。我很難包裝我的服務類的確切角色，一個Service類會爲Book DAO和一個用戶DAO工作嗎？我將爲每個服務類設置一個服務類，讓服務類與DAO交談，獲取結果字符串並將其存儲在我的Book類和用戶類中，然後將該對象發送回控制器。在我看來，Service類是將所有工作委託給其他類的高級類。謝謝你的幫助。服務類別的作用
服務類，被稱爲服務層的集合，是負責執行的企業應用程序的業務邏輯。服務類通常不直接映射到DAO，因爲它們表示可能涉及大量域對象的業務操作。一個例子是訂單提交流程，負責接受訂單的代碼必須與代表訂單，客戶賬戶，財務賬戶和庫存的對象一起工作。
將各種業務操作分離爲不同的服務類是一個設計決策，取決於操作的複雜性，它們之間的相關程度如何，等等。一些設計師可能會決定每個業務操作本質上應該是一個單獨的類（類似於Command pattern），而另一些設計師則更傾向於使用更豐富的各種方法的更全面的界面。
服務層的概念存在，以確保所有的業務邏輯存儲在一個地方，而不是重複。許多現代系統將在後端有幾個接口，例如Web應用程序（可能包含Spring MVC控制器），SOAP或REST接口（可能包含澤西島）以及用於傳統終端或其他系統的專用適配器。使這些接口圍繞公共服務層的所有適配器確保它們都以一致的方式運行，並且對服務層的任何更改都應用於所有訪問接口。
在您的特殊情況下，由於您需要詢問，單個服務對象可能足以滿足您的需求。將所有服務方法列在單獨的interface和代碼上以便您可以替換實現以進行測試或將來的升級是個不錯的主意。
服務類可能充當一個抽象層，因此DAO或數據層對「業務層」隱藏。
該服務可能會與多個DAO進行通信以執行一個功能，在這種情況下，它會更多地使用Facade模式，從而隱藏與DAO進行通信以執行所需功能的複雜性。
這種模式可以在端口和適配器或六邊形架構中看到，因爲業務邏輯與低層協議是絕緣的。
好問題，但可能過於寬泛和主觀的SO。 –
服務幾乎可以做任何事情：圍繞單個DAO的包裝，涉及多個DAO的操作的事務包裝，服務集成商，等等等等。在*你的情況下，爲什麼不問問？ –