Ø ** 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 ”，有兴趣的朋友可以访问如下站点：
**_ 说了许多，又到了“综上所述”时间，作者再次放胆建议： _ **
（ 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 的基
础上 按需裁减 ，或者参考下面的“设计自己的持久层”中提出的方案。
** 作者简介： ** ** **
“ 本文作者张雪峰 是 毕博全球开发中心 的高级开发工程师。他目前在中国上海 毕博全球开发中心 Core/EAI 部门工作，从事 .NET 技术的研究以及相关项目的开发。可以通过 [email protected] 与他联系。 ”