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

类别:.NET开发 点击:0 评论:0 推荐:

 

Ø        Borland ECO

素以提供“多快好省”组件著称的Borland公司在微软发布ObjectSpaces之前率先推出了一套新的开发框架:ECOEnterprise Core Object),先不说其技术特点,就凭其与建模工具Together的无缝集成,不得不让人佩服Borland在统一开发过程方面所下的功夫。

 

根据BorlandECO介绍中的定义,简单说,ECO就是:模型驱动MDA-Driven)的.Net数据库应用Database Application开发框架Framework)。

观点:以作者看来,数据库应用的核心问题就是DAL,也就是本文需要讨论的话题

 

很明显,从MDA-DrivenDatabase ApplicationFrmework这些很具震撼效果的词语不难看出,它们正是Borland公司以前及现在都无比强大的核心竞争力所在(当然,还包括IDEComponentsCross Platform等方面,一个公司能有这么多优秀的产品,实在令人尊敬)!

以前,在Borland平台上开发数据库应用已经非常方便,组件+可视化设计基本可以拿下比较简单的应用模块。如今则更上一层,终于推出了自己的O/R Mapping解决方案!

以作者的观点,在Together这样优秀的Modeling工具加盟下,配合在Framework开发方面的数一数二实力(仅以艺术性而论,VCL Framework就可以拿该领域的奥斯卡奖),目前的ECO绝对稳坐.NET O/R Mapping第一把交椅

(注意:ObjectSpaces尚未发布,暂不考虑。)

 

关于ECO具体开发方面的介绍,大家可以参考“程序员,2003.12P99“程序员,2004.01P97“程序员,2004.02P100

 

以下,作者主要分析利用ECO开发所带来的种种好处及其不足,供各位参考。

 

优点:

(1)    Typed DataSet(类型化的DataSet,在VS.NET中可自动生成)相比具有明显优势;除了可以在UML/

代码间自由切换外,ECO可以支持自定义数据类型

和计算类型(用过Delphi的朋友都知道这是个异常

强大的武器);

 

(2)    IDE提供强大的设计时支持,各种工具、组件一应俱全,这也是Borland最擅长的领域;

 

(3)    集成Together建模工具,将MDA发挥得淋漓尽致;之所以将这条放在第3位,请参考下面的缺点分析;

 

(4)    引入Object Constraints LanguageOCL),该标准得到了OMG组织的官方支持,号称:OO SQL(面向对象的SQL),对于不熟悉SQL的开发人员是一大福音;

 

缺点:

(1)    资源消耗较大,普通机器难以体会其优势;这方面,Rational XDE倒是做得相当不错;

 

(2)    有一定学习曲线,比如:OCLObject Constraints Language),虽然与SQL不同,但从语法角度还不算十分简洁;就作者自己的体会,可能学习XQueryXML中的查询语言)或OPathObjectSpaces中使用的查询语言)要更轻松一些;

 

(3)    纯商业产品,只有Architect版本才包含此功能,而ObjectSpaces直接包含在.NET Framework中,与VS.NET版本无关,可以通过.NET Framework SDK直接使用;

 

(4)    轻微过度MDADAL开发人员既然可以在ECO中生成数据库脚本,那DBA是否也需要在ECO中进行设计呢?

对于企业级应用,作者个人以为:MDA开发模式比较适用于DAL以上各层的开发,如:System ArchitectureBusiness FaçadeBusiness Logic,甚至User Interface,而对于Data Storage,可能并不是非常需要MDA介入。

试想一下,O/R Mapping提供了映射关系,就是希望将RDBMS与其它层分离,如果现在全部在一个地方搞定,那岂不是又加重了开发人员的负担(有时候自动化不见得越多越好)?

还有一点:ECO宣称“代码/UML双向同步”,但并没有保证“代码/字段可以不同”,这就在一定程度上丧失了灵活性

(提示:UML中“同步”意味着设计方案与代码框架“一致”,但在O/R Mapping中,反而不要求这种“一致”,只需要在DALSchema间建立对应关系既可,而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.NETDAL实现方式不同,O/R Mapping有巨大

优势,但也同时隐藏着风险

 

n        最严重的问题就是与存储过程的冲突

众所周知,O/R Mapping的本质是映射,在这方面各类实现

都有其严格定义,说白了,就是将表操作转化为对象操作。

但存储过程的灵活性(传入参数,返回结果等)却不得不使

其暂时地被排除在O/R Mapping大家庭外(至少在目前,上

述介绍过的OJBObjectSpaces等方案都不支持存储过程);

另一方面,如果我们希望实现比较复杂的数据逻辑时,却不

得不以新的Object Language(如:OCLOQL等)书写原

本可以封装在存储过程中的复杂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] 与他联系。

 

本文地址:http://com.8s8s.com/it/it44921.htm