EMF学习，为了实现可扩展可自定义的模型验证 - 各类实现方法学习

自：

　　http://blog.csdn.net/javaman_chen/article/details/6057033

　　http://www.ibm.com/developerworks/cn/opensource/os-cn-ecl-emfvldt/

　　http://blog.csdn.net/james999/article/details/1624747

EMF Validation Framework 提供了对 EMF eObjects 的校验框架，和 EMF EValidator API 相比它能提供更复杂全面的验证而且易用易扩展。EMF Validation Framework 提供了灵活的验证定义方式，支持两种验证触发机制：Batch 和 Live。它支持用 JAVA 和 OCL 语言来实现约束，此外它还支持自定义验证时的模型扫描算法，并提供了一个 Validation Client Context 来规避没必要要的验证。

EMF模型的验证主要经过ModeValidationService类的调用来完成，该类还声明了一个工厂方法newValidator()用于获取IValidator的实现类。IValidator执行器会从Validation Service模块中获取所匹配的Constraint进行验证。IValidator的子接口有两个，分别是ILiveValidator和IBatchValidator，对应模型的验证方式是Live模式仍是Batch模式；而模式的区分经过EvaluationMode来指定。

验证总体须要如下几步：

1.构建约束。

2.注入验证环境

3.将约束与Application进行绑定

4.书写验证主体

 

1.  构建约束

目前支持三种方式：Java Code，EMF Model，以及OCL。全部的约束必须实现 IModelConstraint 接口，定义了验证执行的逻辑（validate()），并拥有一个约束描述符（一个实现 IConstraintDescriptor 接口的类），该描述符包含了这个约束的源信息，例如，验证模式是 live 仍是 batch，验证的目标对象等。不一样的Constraint Model类型下会有不一样的实现。由于Validation Framework这套构架依赖于在plugin.xml中描述和申明来注册相应的constrain实现，因此须要不一样的Parser负责解析和管理。

1.1 java方式。约束的构建主要经过继承AbstractModelConstraint抽象类来完成。AbstractModelConstraint使用了IValidationContext接口做为validate()的方法参数，而且返回Istatus对象用来封装验证结果。//validate(IValidationContext ctx)

IValidationContext对象

（1）提供了当前验证环境的相关信息，包括：
　　target:所验证的目标对象；
　　eventType:表示Live模式下触发验证操做的事件；
　　currentConstraintId:当前所执行的约束Id，等等...

(2) 提供了一些提升验证效率的方法，例如能够用来指定一些的目标对象是“合格的”能够不执行某些验证方法，缓存验证对象。

在validate方法中，若是约束得评估没有经过，可调用IValidationContext接口定义的createFailureStatus(Object... args)方法返回错误状态类型相反，若是评估成功，可调用createSuccessStatus()方法返回成功状态类型。

1.2 OCL

使用EMF OCL很是简单，使用QueryFactory构造一个Query对象，设置表达式（Express），以及表达式所依赖的Context（在EMF OCL中，通常是Classifier）。而后对给定eObject对象进行检查和计算。——就这么简单。

 

Query query = QueryFactory.eINSTANCE.createQuery(     "Book.allInstances()->select(b : Book | b <> self and b.title = self.title)",     LibraryPackage.eINSTANCE.getBook()); query.setExtentMap(extents); Collection result = query.evaluate(myBook);

2. 注入验证环境

经过实现org.eclipse.emf.validation.constraintProviders扩展点完成约束的注入。

3.与Application进行绑定

经过org.eclipse.emf.validation.constraintBindings扩展点来实现该功能。

只能在EclipseRCP环境下运行,并且编写扩展点的实现也很是的繁琐。

4.书写验证主题，参照验证逻辑变下

Batch的验证逻辑为：

指定验证对象，可使一个EObject或其集合  List objects = myResource.getContents();
经过验证服务ModelValidationService构建IBatchValidator
经过EvaluationMode.BATCH指明为Batch模式                                                                                                                                                        IValidator validator = ModelValidationService.getInstance().newValidator(EvaluationMode.BATCH);
validator.setIncludeLiveConstraints(true);//包含Live模式的约束  验证约束这里不须要指定，由于后面的验证是须要注册如application的，而不是添加，而约束能够经过过滤器设置，这里使得验证很难灵活的在使用中添加新的约束。
//能够添加约束的过滤设置   validate.addConstraintFilter(new IConstraintFilter() {...
模型的验证返回IStatus对象 IStatus results = validator.validate(objects);
判断验证状态  if (!results.isOK()) {ErrorDialog.openError(null, "Validation", "Validation Failed", results); }

 

另外一种方式//只是替换现成的Validator的实现

用户还可本身编写EValidator的实现，而后将该实现类注入到EValidator注册表中去，同样可完成模型验证操做，
且这种方式无需编写扩展点的实现，所以只须要OSGI环境就能够了。

1. 编写EValidator的实现

（1）若直接在模型中指明了约束，能够经过*.genmodel文件，是能够直接生成对应的EValidator实现类的。

2. 添加到EValdator注册表中

对应代码

3. 编写模型的验证代码

设置验证目标对象 Object target=getTartget();
Diagnostician diagnostician=new Diagnostician();
BasicDiagnostic diagnostic=diagnostician.createDefaultDiagnostic(target);
Map<Object, Object> context = diagnostician.createDefaultContext();
执行验证操做 diagnostician.validate(library, diagnostic, context);

评估：

有两点可能阻碍实现可扩展、可自定义的验证：

1. 不单单须要验证逻辑的实现，并且须要注册，设置扩展点能操做来具体的配置约束，可不能随意添加自定义的约束

2. 每条约束对应一段代码，如何添加自定义的验证须要思考，这里能够参考OCL验证引擎的实现，北大硕士论文