注册会计师（注会）练习软件--转贴:对象化查询之OCL vs. OPath

对象化查询之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的资料也少，很多都是无关痛痒的简单操作，这让人弄不明白到底是它的语法就这么简单还是另有其它的增强。)

阅读全文(3024) | 回复(0) | 编辑 | 精华

发表评论：

昵称：
密码：
主页：
标题：

验证码： (不区分大小写,请仔细填写,输错需重写评论内容！)

站点首页 | 联系我们 | 博客注册 | 博客登陆

Sponsored By W3CHINA
W3CHINA Blog 0.8 Processed in 0.080 second(s), page refreshed 144778795 times.
《全国人大常委会关于维护互联网安全的决定》《计算机信息网络国际联网安全保护管理办法》
苏ICP备05006046号