代碼分層架構的靈活性和最佳實踐
軟件系統設計中，合理的代碼分層至關重要。本文探討Service層和Mapper層（或DAO層）在mvc架構中的交互，特別是關于單一Mapper調用限制的爭議。
傳統MVC架構包含Controller、Service和Mapper三層。Controller接收請求，Service處理業務邏輯，Mapper負責數據訪問。 文章以獲取用戶信息和部門信息為例，引發了關于Service層設計和層間調用關系的討論：一個Service是否只能調用一個Mapper？多個Service之間能否互相調用？Controller是否應該直接調用多個Service？ 一種觀點認為，應遵循嚴格的單一調用原則（一個Controller對應一個Service，一個Service對應一個Mapper）。這種模式是否過于僵化，在實際應用中是否可行？
更靈活的方案是將架構細化為Controller、Service、Repository（DAO）和Entity（VO）四層。Repository層通常與Entity層一一對應，負責數據持久化和實體對象封裝。Service層和Repository層、Controller層和Service層之間則無需嚴格的單一對應關系。一個Controller可以調用多個Service以滿足復雜業務需求，一個Service也可以調用多個Repository來完成數據訪問。
獲取用戶信息和部門信息的場景，正是Service層內部數據組合的典型例子。將加載用戶數據和部門數據的邏輯分別封裝在UserService和DepartmentService中，是更合理的做法。雖然兩者存在業務關聯，但這并非強耦合。這種關聯源于業務邏輯本身，難以完全解耦。關鍵在于清晰劃分每個Service的職責，并通過合理設計降低模塊間依賴。
因此，與其追求絕對解耦，不如專注于合理的模塊劃分和職責分離，從而提升代碼的可維護性和可擴展性。
