題外話:為了不再誤解,關於造輪子的事情在本篇開頭再次重點提出,如果您覺得再造輪子的人是傻瓜,那直接無視我以及我的附帶品好了.本文的重點並不是做了一個驗證框架,真要如此,直接給出代碼不就結了,或者直接來篇如何使用DataAnnotations即可,何必長篇大論來一通,如果認真看了本文就可以知道本文是講解了如何使用TDD的方法來實現一個驗證框架,同時盡可能做到通俗易懂,當然,這並不是說本文造的輪子就沒有價值了,別人的總是別人的,驗證框架並不是一個很復雜的東西,一個人做出一個完善的也不是什麼難事,也許在某些時候土炮就比洋炮好用也說不准,最後,希望各位手下留情.
說了一通廢話,下面開始正文了,本篇的重點是解決前篇的代碼靈活性問題,前一篇我們對實現了兩個驗證屬性,但是確遇到了新的問題,方法中代碼量的激增以及死板的驗證方式無法讓我們靈活的擴展該框架,窮則變,變則通,我們不得不想辦法解決這個問題,從目前的代碼看,實體的Validate方法明顯有問題,它的責任明顯太多,勢必要對其進行重構,要把它的責任分離出去,如何分離呢?
我們完全可以這樣考慮,現在的驗證屬性僅僅申明了驗證參數,而且如果有很多屬性參數也會不同,驗證的模式也各不相同,那為什麼不讓驗證屬性自食其力,自力更生呢?自己的限制,自己驗證多好.因此考慮擴展驗證屬性的功能,既然驗證是一種契約,一種公共行為,我們免不了設計一個接口來負責這部分的內容,考慮下面的接口:
這樣一來我們就可以在xxxAttribute中實現相應的驗證邏輯了,首先確定新的驗證代碼,對3個屬性進行全面驗證測試:
然後我們開始重構RangeAttribute和RequiredAttribute類,下面的圖片分別展示了兩個屬性中的驗證邏輯
