一、分層政策
MVC模式與代碼分層政策，MVC全名是ModelViewController即模型－視圖－控制器，作為一種軟體設計典範，用一種業務邏輯、資料、界面顯示分離的方法組織代碼，将業務邏輯聚集到一個部件裡面，在改進和個性化定制界面及使用者互動的同時，不需要重新編寫業務邏輯，這是一種開發模式，但并不是實際開發中代碼的分層模式，通常SSM架構的後端代碼分層如下：
controller控制層：定義服務端接口，入參出參，和一些入參校驗；
service業務服務層：組裝業務邏輯，業務校驗，建構控制層需要的參數模型；
dao資料互動層：提供服務層需要的資料查詢方法，處理資料互動條件相關的邏輯；
mapper持久層：基于mybatis架構需要的原生支援，目前很常用的持久層元件；
二、控制層
1、Rest接口風格
基于資源通路和處理的邏輯，使用不同風格的注解。例如資源新增，更新，查詢，删除。
2、接口複用度
不建議接口高度複用，例如增删改查都各自對接接口即可，基本原則，不同的用戶端端操作，對于獨立的接口。
例如常見的list接口，list通常都有會按條件加載的search機制，而且搜尋的判斷條件很複雜，建議分為兩個接口，從實際考慮，大部分場景下都是隻使用list接口，很少使用search搜尋。
3、入參出參
校驗用戶端必須條件，例如某某條件必填必選等，如果有問題，快速阻斷請求鍊路，做到程式入口控制層攔截傳回。
參數在三個以下，可以直接陳列入參，參數在三個或三個以上可以使用實體類統一封裝。
4、參數處理
出參格式處理度基本原則，伺服器作為公共資源，避免非必要操作，例如用戶端可自行判斷傳回值是否為空，null等，或者一些常見格式處理，利用用戶端适當分擔伺服器壓力。
三、業務服務層
1、業務校驗
例如傳入訂單号，經過資料庫層查詢，沒有訂單資料，這裡稱為業務性質的異常，代碼本身沒有問題，但是業務邏輯無法正常執行。
2、組裝業務邏輯
通常情況下服務層作為邏輯做複雜的一塊，用來拼接業務核心步驟，可以通過業務邏輯判定，一步一步執行程式，避免在程式入口做大量可能用到的對象建立和需求資料查詢。
3、資料模型建構
通常情況業務層是偏複雜的，如果想關快速了解業務層，可以對複雜的業務方法，在提供一個返參建構的方法，用來處理服務層要向控制層回傳的參數，這樣可以讓重度的服務層方法變的清晰。
四、資料互動層
1、逆向工程
這裡以使用mybatis架構或者mybatis-plus架構作為參考。如果是mybatis架構，建議逆向工程的模闆代碼不做自定義的修改，如果需要自定義方法，在mapper和xml層面再自定義一個擴充檔案，用來存放自定義的方法和SQL邏輯，這樣避免表結構變動大引發的強烈不适。
當然現在大部分都會mybatis-plus作為持久層元件，可以避免上述問題。
2、資料互動
針對業務層的需要，提供相應的資料查詢方法，隻處理與資料庫互動的邏輯，避免出現業務邏輯，尤其在分布式架構下，不同服務的資料查詢群組裝，不應該出現在該層。
五、源代碼位址