剖析.Net下的数据访问层技术(5)

　　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有巨大优势，但也同时隐藏着风险：最严重的问题就是与存储过程的冲突！众所周知，O/R Mapping的本质是映射，在这方面各类实现都有其严格定义，说白了，就是将表操作转化为对象操作。但存储过程的灵活性（传入参数，返回结果等）却不得不使其暂时地被排除在O/R Mapping大家庭外（至少在目前，上述介绍过的OJB、ObjectSpaces等方案都不支持存储过程）；另一方面，如果我们希望实现比较复杂的数据逻辑时，却不得不以新的Object Language（如：OCL、OQL等）书写原本可以封装在存储过程中的复杂SQL语句。而且，即使写出了这些数据逻辑，也会令人感觉非常古怪甚至丑陋（某种意义上，这也违背了O/R Mapping的初衷）！第二个问题是：在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的基础上按需裁减，或者参考下面的“设计自己的持久层”中提出的方案。