Spring MVC 整合 MyBatis：為何不建議將 Mapper 直接注入 Controller？

分層架構的核心考量

在 Spring MVC 整合 MyBatis 的標準開發模式中，我們通常遵循「Controller → Service → Mapper」的調用鏈路。許多初學者會疑惑：為什麼不直接在 Controller 中注入 Mapper 接口，省去 Service 層？

直接注入 Mapper 的弊端

若將 Mapper 直接注入 Controller，會導致表現層與數據訪問層強耦合。Controller 的職責本應是接收請求、參數校驗、協調服務並返回視圖，不應包含業務邏輯或 SQL 相關操作。一旦業務變更，Controller 代碼將膨脹難維護，且難以實現事務管理、異常統一處理等橫切關注點。

Service 層的價值

• 業務封裝：將核心業務邏輯、事務控制集中在 Service 實現類中，保持 Controller 輕量。
• 複用性：多個 Controller 可復用同一 Service 方法，避免代碼重複。
• 擴展性：引入 AOP、緩存、異步處理等均在 Service 層完成，不污染控制層。

關於「通用執行類」的反模式

問題中提到的「實現 ApplicationContextAware 從容器獲取 Mapper 並反射調用」屬於典型的反模式：

1. 繞過 Spring 依賴注入機制，增加運行時錯誤風險；
2. 反射調用損失編譯期類型檢查，降低代碼可讀性與性能；
3. 將前端傳入的方法名直接映射到後端調用，存在嚴重安全隱患（任意方法執行）。

最佳實踐總結

堅持分層架構，Controller 僅做請求分發，Service 聚焦業務邏輯與事務，Mapper 專注數據持久化。這樣才能構建高內聚、低耦合、易測試、可維護的企業級應用。