前索引：
圍繞EMF探索（1）之存儲和查詢
前索引： 圍繞EMF探索（2）之再探查詢組件
前索引： 圍繞EMF探索（3）之初探OCL
前索引： 圍繞EMF探索（4）之Validation組件圖
圍繞EMF探索（5）之深入Validation框架
前索引： 圍繞EMF探索（2）之再探查詢組件
前索引： 圍繞EMF探索（3）之初探OCL
前索引： 圍繞EMF探索（4）之Validation組件圖
圍繞EMF探索（5）之深入Validation框架
在EMF的eCore框架中，本身提供了對Validation Framework的支持，而EMFT的Validation組件則是在這個基礎上又擴展的大量的功能。如果大家采用Validator Adaptor方式，可能會更加體會到對Evalidator的應用。
但是由于EValidator是在注冊過程中，是依據EPackage來匹配的，針對一個ePackage一般只能注冊一個Evalidator對象。這就限制的應用的擴展性。
|
EValidator.Registry.INSTANCE.put(
LibraryPackage.eINSTANCE, new LibraryValidator());
|
而EMFT的Validation Framework則在這個基礎之上進行了擴展，但是Validation Framework沒有在EObjectValidator的基礎上進行擴展，而是另辟蹊徑，構造了自己的一套實現構架，甚至完全拋棄了EMF eCore所提供的DiagnosticChain機制，而是采用eclipse runtime IStatus對象來記錄校驗的結果。
為了便于理解，繪制了一張EMFT Validation Framework的主要構思圖：
整個EMFT Validation Framework的核心就是兩個概念：IValidator和Constraint。其中IValidator是有別于EMF eCore的EValidator。IValidator是一個驗證執行器，為了支持對Batch和Live兩種模式的支持，所以有不同的接口和實現類。Batch模式就是可以對批量對象進行驗證，而Live模式則可以在對象值變更的時候相應驗證。
IValidator
執行器會從Validation Service模塊中獲取所匹配的Constraint進行驗證，當然，為了優化和便于管理，Validation Framework還提供了對Context、Binding、ProviderOperation等方面的支持。不論如何，最終的解決目的就是為了找出合適的Constraint進行驗證。
有關Constraint的代碼，幾乎占據了Validation Framework代碼量的大部分，其實解決的目的就是為了可以方面的支持多種Constraint Model，目前支持三種方式：Java Code，EMF Model，以及OCL。
在Validation Framework構架中，真正用于constraint validate是ImodelConstraint接口，不同的Constraint Model類型下會有不同的實現。
因為Validation Framework這套構架依賴于在plugin.xml中公國描述和申明來注冊相應的constrain實現，所以需要不同的Parser負責解析和管理。看看下面的類圖，應該就比較清晰了。
當然，在我們使用Validation Framework這套框架的過程中，是不會接觸到 這些parser的，甚至根本不知道IModelConstraint的存在。
比如，針對java模式，一般我們會繼承一個AbstractModelConstraint類來實現。如下圖所示：
事實上，這是一個很簡單的Adapter模式的應用，具體就沒有必要細說了，類圖已經很清晰的反映了一切。
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
