SSM框架的實際使用流程

一、以用戶登錄功能爲例，可以分爲四步：

1. 用戶-登錄-持久層

(a) 分析需要執行的SQL語句

(b) 接口與抽象方法

© 配置映射

2. 用戶-登錄-業務層

(a) 創建異常

(b) 接口與抽象方法

© 實現業務

3. 用戶-登錄-控制器層

(a) 處理異常

(b) 設計需要處理的請求

• 請求路徑：/users/login
• 請求參數：String username, String password
• 請求類型：POST
• 響應結果：JsonResult<User>

© 處理請求

4. 用戶-登錄-前端頁面

二、細節：

• 在創建數據表時，能夠使用數字作爲標記的字段，應該使用數值類型，例如“性別”；
• 在創建數據表時，如果字符串的長度固定，應該使用char，如果長度不固定，應該使用varchar；在使用varchar時，應該指定比上限值略大的限制值，例如“用戶名”的長度上限爲16，則應該設置爲varchar(20)或略大於16的其它值；
• 在創建數據表時，應該明確通過charset=xx指定字符編碼，且推薦使用utf8mb4；
• 在創建實體類時，每個屬性都應該是私有的，應該爲每個屬性添加Getters & Setters，應該基於id這種唯一標識對應的屬性生成hashCode()和equals()（無視方法內容），應該生成完整的toString()以便於觀察各屬性的值，應該實現Serializable接口並生成其ID；
• 在開發每個功能的各層時，每完成一層，就應該及時測試，持久層和業務層可以通過單元測試來完成測試，控制器層可以通過在瀏覽器直接輸入URL及測試參數來完成測試，一定要保持“做一層，測一層，測試通過再做下一層”的原則；
• 無論是開發哪一層，都應該保持“先分析，再開發，再測試”的原則；
  
• 持久層的主要職責是完成數據的增刪改查，並不關心數據從哪裏來，也不關心是否應該執行增刪改查中的某些操作，這些問題都應該是業務層關心的，所以，持久層的每個功能都非常單一，只關心數據訪問的實現；
• 業務層的主要職責是組織業務流程（執行先後順序），實現業務邏輯（判斷是否應該），以保障數據的安全性（數據按照我們設定的規則而產生或發生變化）和完整性（凡不應該由用戶提交的數據，都在服務器端的業務層中補全）。
• 業務方法的返回值都是基於“以操作成功爲前提條件”來設計的，如果在業務的實現過程中，判定爲“失敗”，則應該拋出相應的異常對象，並且，在拋出時，通過異常的構造方法封裝“失敗”的描述信息；
• 應該爲每一種錯誤都創建對應的異常類，且需要有1個自定義異常的基類，其它自定義異常都應該直接或間接的繼承自這個基類，而基類異常需要繼承自RuntimeException；
• 應該使用統一處理異常的機制對各種可能出現的異常進行處理；
• 無論是業務層，還是控制器層，在對數據的處理流程不夠清楚的情況下，或在數據不符合預期的情況下，應該在關鍵時間點打樁輸出相關數據；
• 當完成了前端頁面的開發，且點擊按鈕或進行某些操作時，如果沒有預期的結果，甚至頁面完全沒有反應，應該打開瀏覽器的Console面板和Network面板，然後，再次執行不符合預期的操作，並觀察這2個面板中是否存在可參考的信息。