- 誰來做Validation
- 何時做Validation
- 如何表達錯誤
- 如何傳遞錯誤
- 如何關聯錯誤到發生錯誤的對象, 尤其是對象圖中非Root對象
這里的Validation指的是對進入到系統中的業務數據的校驗(不包括Web應用中頁面數據在瀏覽器端的驗證)
誰來做Validation
數據的有效性不是自身所能決定的, 而是使用它的場景(Context)決定的, 因此,
每個Context應該有自己的Validation邏輯.
一個例子, 個人信息殘缺, 比如婚姻狀況沒填, 但聯系地址電子郵件等信息完備,
那么這個個人信息到底是合法還是非法? 如果你的應用是個稅務相關的應用必須知道婚姻狀況則數據是非法的,
如果你的應用是CRM系統有客戶的聯系方式即可而婚姻狀況是可選的則數據就是合法的. 問題是你的應用是稅務應用但同時支持客戶關系管理, 那這段數據到底合法非法?
稅務應用只是年底的時候才有人用, 而客戶關系管理系統隨時都有人用, 假設數據是通過頁面提交的, 那這批數據到底該拒絕還是接受?
何時做Validation
通常有幾個時機, 對象被創建出來, 對象狀態改變, 以及對象被持久化. 企業應用中同一份數據一般至少有兩種存在形式: 在數據庫中的持久化狀態,
以及在內存中以編程語言定義的對象形式存在. 那么幾個時機:
- 手動創建對象, 就是應在構造函數中做驗證
- 框架幫忙創建對象, 比如從頁面Form綁定到Server端的對象時, 可以在綁定完成的那一刻做校驗
- 存到數據庫里那一刻
這就帶來一個問題: 可能要在三個地方做大體相同的驗證, 如何復用驗證規則?
另一個問題是: 在引入ORM的應用中,
編程語言寫好的驗證邏輯同樣可以應用在持久化到數據庫的那一顆, 那在SQL/DDL語句中定義的約束是否還必要?
如何表達錯誤
有兩個約束:
- 要提供易于用戶和支持人員理解的錯誤信息
- 要提供盡可能豐富的信息
常見的手段是用字符串或者錯誤代碼/ID, 這是不work的, 因為它們合并了錯誤本身和錯誤的表示:
出錯的地方可能距離需要展現錯誤的地方很遠, 或者有多種展現錯誤的界面, 或者有很多顯示方面的需求, 比如支持國際化,
報錯的地方是沒有能力也不需要知道錯誤是如何被展示的, 它要做的是盡可能報告關于錯誤的詳細信息, 包括違反了什么規則, 出錯的字段, 實際的值和期待的值等,
字符串和錯誤代碼/ID是沒有如此豐富的表達能力的
我們可以用對象來表達錯誤信息, 對象的類型可以表示錯誤的類別,
對象的屬性/字段可以攜帶各種與錯誤類型相關的數據. 然后在需要展現給用戶的那一刻, 再把對象翻譯成針對那個界面的顯示, 比如可以做國際化,
或者提供給程序員更技術化的描述. 而在錯誤信息需要被顯示之前, 錯誤在系統中的傳遞,
都是以對象的形式進行的...
聽起來跟異常Exception很像?
幾個反例是.Net平臺上的異常,
比如KeyNotFoundException, 它就不告訴你那個找不到的Key是啥, 還有Index越界, 就不告訴你index的值是多少,
還有數據庫連接超時或者Transaction Timeout,死活不告訴你它等了多久超時的,
讓你搞不清楚是你的超時時間設的太短還是根本你的設置就沒生效
如何傳遞錯誤
收集參數, 輸出參數, Thread Local, 或者拋出異常然后合適的層次捕獲
如何關聯錯誤到發生錯誤的對象圖, 尤其是對象圖中非Root對象
給錯誤一個Key, 這個Key應該能表示出錯的對象在對象圖中的位置, 比如Key可以是字段名稱中間用"."分隔, 級聯起來的字符串.
注意這種形式的key應該是在調用驗證邏輯的地方組裝起來的, 而不應該是驗證邏輯本身,
因為驗證邏輯通常并不知道自己驗證的這個對象在父對象中的字段名稱
一個額外的話題
很多驗證框架采用了基于Attribute/Anontation的方式, 這樣當一個對象在不同的Context有不同的驗證邏輯時就會很糾結,
因為它是以侵入的方式寫到對象的定義中的. 這恰恰從另一個角度說明了對象是不應該跨Context復用的, DCI才是王道