剖析 .Net 下的数据访问层技术（五）
2024-07-10 13:03:38
供稿：网友
菜鸟学堂：
ø borland eco
素以提供“多快好省”组件著称的borland公司在微软发布objectspaces之前率先推出了一套新的开发框架：eco（enterprise core object），先不说其技术特点，就凭其与建模工具together的无缝集成，不得不让人佩服borland在统一开发过程方面所下的功夫。
根据borland在eco介绍中的定义，简单说，eco就是：模型驱动（mda-driven）的.net数据库应用（database application）开发框架（framework）。
（观点：以作者看来，数据库应用的核心问题就是dal，也就是本文需要讨论的话题）
很明显，从mda-driven，database application和frmework这些很具震撼效果的词语不难看出，它们正是borland公司以前及现在都无比强大的核心竞争力所在（当然，还包括ide、components、cross platform等方面，一个公司能有这么多优秀的产品，实在令人尊敬）！
以前，在borland平台上开发数据库应用已经非常方便，组件+可视化设计基本可以拿下比较简单的应用模块。如今则更上一层，终于推出了自己的o/r mapping解决方案！
以作者的观点，在together这样优秀的modeling工具加盟下，配合在framework开发方面的数一数二实力（仅以艺术性而论，vcl framework就可以拿该领域的奥斯卡奖），目前的eco绝对稳坐.net o/r mapping第一把交椅！
（注意：objectspaces尚未发布，暂不考虑。）
关于eco具体开发方面的介绍，大家可以参考“程序员，2003.12，p99”，“程序员，2004.01，p97”，“程序员，2004.02，p100”。
以下，作者主要分析利用eco开发所带来的种种好处及其不足，供各位参考。
优点：
（1） 与typed dataset（类型化的dataset，在vs.net中可自动生成）相比具有明显优势；除了可以在uml/
代码间自由切换外，eco可以支持自定义数据类型
和计算类型（用过delphi的朋友都知道这是个异常
强大的武器）；
（2） ide提供强大的设计时支持，各种工具、组件一应俱全，这也是borland最擅长的领域；
（3） 集成together建模工具，将mda发挥得淋漓尽致；之所以将这条放在第3位，请参考下面的缺点分析；
（4） 引入object constraints language（ocl），该标准得到了omg组织的官方支持，号称：oo sql（面向对象的sql），对于不熟悉sql的开发人员是一大福音；
缺点：
（1） 资源消耗较大，普通机器难以体会其优势；这方面，rational xde倒是做得相当不错；
（2） 有一定学习曲线，比如：ocl（object constraints language），虽然与sql不同，但从语法角度还不算十分简洁；就作者自己的体会，可能学习xquery（xml中的查询语言）或opath（objectspaces中使用的查询语言）要更轻松一些；
（3） 纯商业产品，只有architect版本才包含此功能，而objectspaces直接包含在.net framework中，与vs.net版本无关，可以通过.net framework sdk直接使用；
（4） 轻微过度mda：dal开发人员既然可以在eco中生成数据库脚本，那dba是否也需要在eco中进行设计呢？
对于企业级应用，作者个人以为：mda开发模式比较适用于dal以上各层的开发，如：system architecture，business façade，business logic，甚至user interface，而对于data storage，可能并不是非常需要mda介入。
试想一下，o/r mapping提供了映射关系，就是希望将rdbms与其它层分离，如果现在全部在一个地方搞定，那岂不是又加重了开发人员的负担（有时候自动化不见得越多越好）？
还有一点：eco宣称“代码/uml双向同步”，但并没有保证“代码/字段可以不同”，这就在一定程度上丧失了灵活性！
（提示：uml中“同步”意味着设计方案与代码框架“一致”，但在o/r mapping中，反而不要求这种“一致”，只需要在dal与schema间建立对应关系既可，而borland将传统建模的思想照搬到dal设计中，作者认为是值得商榷的。这方面，其它的o/r mapping方案就做得比较自然，突出了“mapping”的含义，而不仅仅是简单的“synchronization”。）
ø 其它
还有一些其它的技术也可以实现o/r mapping或类似功能，就作者试用过的一些解决方案来说，constructor（国外）、grove（国内）都是不错的选择，constructor甚至号称“model driven rad for .net”，有兴趣的朋友可以访问如下站点：
http://www.dotnetbuilders.com
http://grove.911link.com
说了许多，又到了“综上所述”时间，作者再次放胆建议：
（1）与基于ado.net的dal实现方式不同，o/r mapping有巨大
优势，但也同时隐藏着风险：
n 最严重的问题就是与存储过程的冲突！
众所周知，o/r mapping的本质是映射，在这方面各类实现
都有其严格定义，说白了，就是将表操作转化为对象操作。
但存储过程的灵活性（传入参数，返回结果等）却不得不使
其暂时地被排除在o/r mapping大家庭外（至少在目前，上
述介绍过的ojb、objectspaces等方案都不支持存储过程）；
另一方面，如果我们希望实现比较复杂的数据逻辑时，却不
得不以新的object language（如：ocl、oql等）书写原
本可以封装在存储过程中的复杂sql语句。而且，即使写
出了这些数据逻辑，也会令人感觉非常古怪甚至丑陋（某种
意义上，这也违背了o/r mapping的初衷）！
n 第二个问题是：在o/r mapping的环境中，系统的执行效率将有一定损失，即使使用了cache management（一次性装载配置文件）或者delayed loading（又称lazy loading，只在访问实体类数据时才真正连接数据库）技术，由于在初次装载数据时使用了reflection机制去定位实体类（在某些方案中，映射关系以.net attribute方式体现，则更花时间），所以肯定不如直接通过ado.net填充数据来得那么快！
如果各位认为上述风险不是问题，那下面的各条就是作者的真正
建议了。
（2）在大型应用（一般指企业级应用）开发中，eco是很好的
选择；
（3）如果是普通n-tier应用，则objectspaces足矣；
（4）想要学习o/r mapping的朋友，可以看看opf / ojb源码，
这两个方案的实现思路与eco / objectspaces是有一些相似的；
（5）如果不希望使用现成的o/r mapping，则可在opf / ojb的基
础上按需裁减，或者参考下面的“设计自己的持久层”中提出的方案。
