围绕EMF探索（5）之深入Validation框架

前索引：围绕EMF探索（1）之存储和查询
前索引：围绕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模式的应用，具体就没有必要细说了，类图已经很清晰的反映了一切。