前索引：
围绕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模式的应用，具体就没有必要细说了，类图已经很清晰的反映了一切。
