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