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