对象化查询之OCL vs. OPath

令人心动的对象化查询

对象化查询是O/R Mapping中非常让人心动的一个特性，当所有的表对我们来说不复存在后，我们可以对实体进行CRUD，可是当我们需要返回多个实体的结果集时，我们怎么办呢？Dataset做为载体是必然的，可是我们查询过滤数据的方式是怎样的？sql？No！我们就是在尽量避免直接使用sql，因为sql不便于重构，可移植性太差，拼凑出来的sql语句对测试覆盖率也有影响。所以大家都期待着可以用对象化查询来根除将Entity再当做Table来处理的尴尬。

 

.Net下的O/R Mapper对对象化查询的支持

目前为止，.Net下的O/R Mapper对对象化查询的支持绝大部分都是非常有限的：NHibernate用的是HQL语句，其本质可以说是一种把Entity看做Table的改装后的sql语句，DataObjects.Net和NHibernate差不多，也有一套自己的类sql对象化查询语法，其它很多O/R Mapper使用的是简单的属性过滤查询，而说到对对象化查询支持得最强大的，要算ECOⅡ和ObjectSpaces，前者使用的是OCL语法，后者是OPath。

 

OCL起源

OCL是OMG组织制订的UML语言规范的一部分，它的初衷是用来对UML模型视图中的Object添加约束描述的，并不是一种编程语言，而OCL应用到O/R Mapping中就俨然成了一种对对象进行查询的语言（OQL）。

 

OPath起源

OPath是MS提出的在WinFS中准备大量使用的一种对象查询语言，从它的命名上可以看出和XPath的相似之处，MS的口号一直是把复杂的东西变简单，把简单的东西变成自动化。所以这个OPath确实不可小觑。

 

简单的例子

先我们从一个简单的例子入手，假设有如下的实体关系（画图太麻烦，还浪费空间）：

Department (code name employees)

Employee(code name department salary)

查询	OCL	OPath
包含薪水大于3000的员工所有部门	Department.allInstances->select(self.employees.includes(salary > 3000))	Exists(employees[saleary > 3000])
得到部门001的所有员工	Employee.allInstances->select(self.department.code = ‘001’)	Department.code = ‘001’
所有员工薪水都大于3000的部门	Department.allInstances->select(self.employees.forAll(salary > 3000))	不支持
员工最高薪水大于3000的部门	Department.allInstances->select(self.employees.includes(salary > 3000))	不支持

 

功能比较

从这个列表中可以看到OPath的语法要简洁得多，但OCL的集合操纵能力却是OPath无法比拟的，下面是OCL的一些集合函数：

名称	功能
Collect	得到一个属性的集合
Exists	如果存在符合条件的元素为真
forAll	只有所有集合元素符合条件时才为真
Includes	是否包含某个对象
Select	获取符合条件的一个子集
Reject	减去符合条件的一个子集
IsEmpty	集合为空
NotEmpty	集合不为空

此外，ECOⅡ对集合操作还有增强，如提供了sum、avg、max、min的聚集操作函数，同时它还支持多种非聚集函数，如concat、length、toupper、tolower等。

 

其它的一些特性：

特性	OCL	OPath
NULL判断	支持	支持
Implies(表示如果左边为真，那么右边也要为真)	支持	A implies B可以转化为(A and B) or (Not A)
类型判断和转换	支持	无
Distinct	支持（通过Set集合返回）	不支持（因为只是对象获取和属性过滤，没有集合操作，所以不涉及到子集合，而外部对象集合一般有主键约束）
集合内元素获取	支持	不支持
Order By	支持	不支持，但可以通过调用查询对象的方法达到目的

 

假如增强OPath的话，大概会是什么样子？

如果要支持集合操作的话，那么现有的OPath语法的简单性肯定要大打折扣，比如说类似于OCL中的forAll，OPath如果要实现的话，可能的方法就是：

(Employees[salary > 3000].Count = Employees.Count)

 

性能比较

因为现在ObjectSpaces中的OPath语句最后都将转为SQL执行，所以它的性能是非常好的（时这也正是它功能无法强大的弱点），而OCL的语法只有部分才能转化为SQL，因此在ECOⅡ中，还有部门的OCL操作必须针对内存对象来进行，这样也就使得必须装载大量的实体对象到内存中。

 

你将选择哪种查询？

就我个人而言，我倾向于增强型的OPath。毕竟更加复杂的查询我们可以通过view和store procedure来完成，就算OCL再强大，也无法涵盖我们需要的查询功能，其内存对象操纵的性能问题不能不让我们谨慎使用，而ECOⅡ可以算是一个MDA的框架，这也让我对MDA的将来感到一些担忧，除非ANSI SQL进化到了可以更加强大的地步，各数据库本身就可以完成OCL所需要的查询功能，但这个时候，也许SQL的表达更加直观，那么，我们又为什么需要OCL来查询呢。当然，OCL在UML中的作用我们并不否定，只是直接从模型生成代码的应用似乎只能在不太复杂的场合才生效。

 

(注：因为ECOⅡ的资料很少，很多是参考它的前身bold for delphi的语法，而OPath的资料也少，很多都是无关痛痒的简单操作，这让人弄不明白到底是它的语法就这么简单还是另有其它的增强。)