ECO传奇（II）

转载

mob604756ec7b7c 2007-12-17 10:52:00

文章标签 开发人员 .net 程序代码数据库业务逻辑 文章分类 代码人生

ECO传奇（II）

详细看看这个模型，它不但定义了类、方法和特性，更重要的是它详细地定义了一个实际的论坛系统中类之间的关系，因此，ECO执行时期就可以自动执行这些设计的关系，例如如果我们想要在一个论坛种类（程序设计）中加入两个论坛，那么就可以简单地使用下面的程序代码：

[C#]

Category aCategory = new Category(EcoSpace);

ACategory.Name = “程序设计”;

Forum aForum = new Forum(EcoSpace);

aForum.Name = “ASP.NET程序设计”;

aCategory.owns.add(aForum);

Forum aForum = new Forum(EcoSpace);

aForum.Name = “PHP程序设计”;

aCategory.owns.add(aForum);

[Delphi.NET]

aCategory := Category.Create(EcoSpace);

ACategory.Name := ‘程序设计’;

aForum := Forum.Create(Ecospace);

aForum.Name := ‘ASP.NET程序设计’;

aCategory.owns.add(aForum);

Forum aForum := Forum.Crrate(EcoSpace);

aForum.Name = ‘PHP程序设计’;

aCategory.owns.add(aForum);

之所以会这么简单是因为模型中已经定义了Category和Forum这两个类之间有一对多的关系，而且这两边的关系使用了ownedBy和owns来定义，因此，在程序代码中我们就可以直接使用定义的关系，ECO执行时期由于是执行定义的模型，因此能够了解这些程序代码的意义。这样一来，开发人员只需要遵照模型的定义就可以专心地撰写程序代码，ECO把类之间不管是一对一，一对多，多对多的关系都自动产生了相关的程序代码，开发人员不再需要分心自行建立或是使用额外的数据结构，例如ArrayList或是Collection等。

那么如何把上面程序代码的异动更新回数据库中? 这是非常简单的，因为ECO提供了强大的OR Mapping技术，一旦模型定义完成之后，ECO能够自动地根据模型而执行MDD中的模型转换（Model Transformation）规范而把模型转换为数据库模式。开发人员可以选择要使用的数据库是什么，要使用的数据存取技术是什么，ECO便会自动根据开发人员的设定完成。这个流程就避免前面本文所叙述的开发人员需要不断地在不同的项目中撰写重复的数据存取程序代码。

目前ECO支持了市面上主流的数据库，例如Oracle，MS SQL Server，InterBase，DB2，MySQL和Sybase等。支持的数据存取技术则有ADO.NET和Bdp.NET。下面的图形说明了这个概念。

因此，通过ECO提供的OR Mapping功能，每一个ECO类对象就是一个可永续储存的对象，因此我们就可以使用下面更为简单的程序代码完成储存上面程序代码异动的工作：

[C#]

EcoSpace.UpdateDatabase();

[Delphi.NET]

EcoSpace.UpdateDatabase;

一旦调用了EcoSpace的UpdateDatabse方法，ECO在执行时期就可以自动侦测已经被异动过的对象，然后通过ECO的永续储存服务接口执行OR Mapping的工作把异动的对象储存在数据库中。这样一来，开发人员再也不需要花费时间重复的撰写数据存取程序代码来存取各种不同的数据库，这又避免了前述的开发问题之一。

那么ECO的对象样例如何和.NET的图形用户界面组件在一起使用呢?这个意思是说ECO可以把业务逻辑对象当成是一般的.NET对象（DataSet）进而显示在.NET组件中吗? 当然可以，ECO使用了Adapter技术，让ECO业务逻辑对象可以通过ECO提供的Handler组件和.NET的图形用户界面组件绑定在一起。例如在下图中笔者使用了ECO的Handler组件（ehForumSite）通过OR Mapping从数据库中抽取业务逻辑对象，再直接和.NET内定的ASP.NET Web组件绑定在一起，这样一来，这些被选择的业务逻辑对象在ECO ASP.NET应用程序执行时就会自动显示在浏览器中，就好像是开发人员自己撰写ADO.NET程序代码从数据库中选择数据，建立DataSet对象，再显示于Web组件中一样，但是使用ECO，开发人员可以完全省略重复撰写这些相同程序代码的时间。

当然ECO除了可以绑定ASP.NET的Web组件之外，也可以使用于Winform的应用程序中，相同的业务逻辑模型可以重复使用在ASP.NET，Winform，Web Service和WinCE的应用程序中，大幅节省重复开发的成本。例如下图就是使用前面相同的模型于另外一个Winform项目中执行的画面:

也许现在读者会有一个疑问，那就是前面叙述的ECO的Handler组件（ehForumSite）如何从数据库中抽取应用程序需要的对象呢? 是使用SQL吗? 可是SQL执行的结果应该是数据集（Data Set），怎么会是对象呢?

如果读者有这个疑问的话，那非常好，这代表读者询问到了ECO的一个核心问题，那就是如何从数据库中选择ECO应用程序需要的对象? 答案就是ECO使用MDD的标准规范OCL（Object Constraint Language）语言来执行选择对象的工作。OCL是OMG定义的标准，也是MDD的子规范之一，OCL可以使用在模型中定义业务逻辑，因为OCL定义了许多的操作数，OCL也可以使用于选择对象，提供类似于SQL的能力。只是SQL选择的结果是数据集，而OCL执行的结果则是对象或是对象集。

例如前面的ehForumSite组件即使用了下面的OCL从数据库中选择出所有的论坛网站对象：

ForumSite.allInstances

当然，OCL也定义了丰富的选择操作数让开发人员使用更精确的条件来抽取对象，例如我们可以使用下面的OCL选择出所有论坛种类中包含多于一个论坛主题的论坛种类对象:

Category.allInstances->select(c| c.owns.size() <> 0)

OCL也允许使用巢状或是串联的语法，例如下面的OCL可以抽取出所有有QA问题但是尚未回答的研讨会对象：

DevCoSeminar.allInstances.select(s | (s.hasQA.size() > 0) and (s.hasQA.select(not closed)->size() > 0) )

由此上面简单的叙述可知，OCL可以同时使用在静态的模型中定义业务逻辑，也可以于执行时期动态的使用ECO组件来执行，例如下图就是在ECO应用程序执行时期动态执行OCL并且取得结果对象集:

OCL提供了丰富的运算方式，有兴趣的读者可以在OMG的官方网站找到OCL相关的规范和文件。

为了满足开发人员对于复杂应用程序的开发需求，ECO还提供了丰富的服务框架，例如提供交易管理的服务，执行对象Undo/Redo的服务，快储服务，对象池服务，订阅服等高级应用框架服务，让开发人员能够使用来撰写应用程序。这些服务都是以现代框架架构设计，实作的，也使用了接口导向，让开发人员只需要取得需要服务的界面即可使用ECO服务框架提供的服务而无需开发人员自己花费时间撰写这些应用程序都共通需要使用的功能。

最后我们可以把整个ECO技术提供的架构叙述如下:

n 展示层（Presentation Layer）： ECO提供的各种Handles组件以便让数据和.NET的控件结合在一起。

n 业务逻辑层（Business Layer）：开发人员在ECO类别中实作的程序代码

n 服务层（Service Layer）：ECO框架提供的各种服务，例如处理异动对象的IDirtyListService接口，服务层也是本章讨论的重点。

n 框架层（Framework Layer）：ECO内部的实作程序代码。

下图显示了ECO中服务层和框架层的关系：

· ECO框架的设计架构

由于ECO提供的强大的功能以及丰富的应用程序开发能力，笔者建议有兴趣的读者可以到CodeGear的官方网站下载展示如何使用ECO开发应用程序的影片，就可以了解ECO强大，快速的开发能力。读者可以在下面的URL找到ECO相关的影片和资料:

http://dn.codegear.com/bdntv

http://dn.codegear.com

ECO未来的技术发展

有趣的是，随着OR Mapping技术在Java和.NET平台的成熟并且逐渐为开发人员接受和使用之后，开发人员可以专心在开发业务逻辑对象而不再需要分神于各种不同的数据存取API和框架，开发人员也不需要小心的区别一般类别和需要永续储存的类别。这个意思是指数据存取类别现在已经驱进为程序语言的First Class类别，开发人员只需要遵照程序语言的标准即可以透明的处理和资料来源相关的工作，这实是进代程序语言和信息技术的一大进步，

更有趣的是现在UML建模能力几乎已经成为主流IDE的内建功能，那么当开发人员开始习于使用IDE的UML建模功能以便使用更高阶，抽象的方式来开发应用系统，再结合普及的OR Mapping技术，那么这种工作情形的表达式等于:

IDE + UML建模 + OR Mapping

再想想现在大多数的OR Mapping都定义了特定的语言来查询和处理实体（Entity），例如Hibernate的HQL，JPA/EJB 3的JPQL，那么上面的表达式可以再改为:

IDE + UML建模 + OR Mapping + 对象查询语言(HQL/JPQL)

不过如果我们考虑到为什么在OR Mapping技术成功的消弭了一般实体和数据存取实体之间的籓篱时为什么要要使用这么多种不同的实体查询语言?而且实体查询语言又不能使用在业务逻辑模型之中，那么什么是可以同时使用在高阶企业模型之中定义业务逻辑，又同时能够使用在程序语言中查询业务逻辑对象呢? OCL不正是身兼者之长吗?因此如果我们把OCL带入上面的表达式时可以得到如下的结果:

IDE + UML建模 + OR Mapping + OCL

此时如果我们回去看看MDA/DDA的规范，可以发现UML建模 + OR Mapping + OCL正是关键的技术标准。这意谓着:

UML建模 + OR Mapping + OCL ~= MDA/DDA

而上面表达式中的功能如果提供在现代IDE之中，那么就形成了下面的结果:

IDE + UML建模 + OR Mapping + OCL ~= RAD MDA/DDA

这也就是说MDA/DDA的条件也即将慢慢的普及于未来的IDE之中，也许大多数的开发单位不会使用MDA/DDA全部的功能来开发软件，但是当他们日后阅读有关MDA/DDA的数据时可能会很惊讶的发现到他们早已使用部分MDA/DDA的规范在开发软件。

其实朝向使用MDA/DDA或是使用部分MDA/DDA开发软件是非常自然的发展，当现代程序语言和OR Mapping等技术不断的消除不同技术之间的歧异之后，让对象导向技术往前更迈进了一大步，这也正朝向解决对象导向技术“最后一哩”的关键，那就是让开发人员在使用对象导向技术开发软件时，所有需要使用的技术都是First Class。而当这个目标逐渐达成时，开发人员就自然会从技术细节中脱身，转而从模式或是架构的角度来思考软件，这当然是因为底层的技术都通透化了，进而允许我们达成“编码即建模，建模即编码”，这也正是MDA/DDA的发展的思想。

好了，在简短的说明了软件开发可能的发展趋势之一后，那么在ECO III之后CodeGear会如何持续的发展ECO技术呢? 严格的说，ECO III是一个非常成功的版本，因为ECO III的功能集不但已备完善，非常稳定，而且使用的群组，人数也非常的广泛。因此ECO IV的战略方向应该是朝扩大战果发展，从CodeGear即将公布的路线图中可以了解ECO IV的发展重点如下:

n 延伸支持VCL.NET，让ECO技术能够同时执行在.NET和VCL平台，并且准备为未来的Win64/WinCE平台做准备。

n 更新，更开放的Adapter架构，让ECO框架能够使用更多的数据存取技术来实作OR Mapping能力。除了现在的ADO.NET 1.x和Bdp.NET之外，未来可支持新一代的数据存取框架，例如ADO.NET以及CodeGear明年即将公开，极具创意的新一代架构，甚至是MS未来的OR Mapping技术以及NHibernate。

n 更紧密的结合Web功能，让ECO IV可以使用于ASP.NET 2.0，Ajax应用，Web 2.0等。

n 更快的执行效率，更具延展性的数据库对映功能。

n 在IDE中更多的RAD MDA/DDA功能。

ECO IV将在CodeGear 2007年的产品中现身，其丰富的新功能自然是许多现在已经使用ECO的开发人员期待的新版本。