收获丰富的两个星期和ECO OR Mapping

转载

mob604756f87695 2007-12-17 10:52:00

收获丰富的两个星期和ECO OR Mapping

这段时间我没有写Blog，主要的原因是除了忙于即将到来的技术研讨会之外，另外就是最近在阅读《长尾理论》、《历史家》、《吴清源传》和《林海峰传》四本书。这四本书都非常精彩，让我无法不一次读完它们，因此过去的两个星期都是在阅读和思考中度过的。《长尾理论》和《历史家》这两本书不但让我享受阅读的乐趣，也让我的脑子在阅读时不停地思考。例如阅读《长尾理论》时我不停地思考书中的内容是如何对映到IT界的，《长尾理论》又是如何解释Borland/DevCo最近的状况和演变的，《长尾理论》又是如何可以对映到我的学习之路和未来的发展的。而在阅读《历史家》时除了享受故事内容的同时，我也从IT人的思考角度找到了书籍内容中数个不合理的臭虫，而这一点我太太则是嘲笑我的职业病已经快到了无可救药的地步，不过《历史家》最后的结局却让我思考为什么卓九勒只是“历史家”而不是“程序员”，因为卓九勒发展出来的搜寻技术早己远远超过Google，如果卓九勒把它发展成“吸血鬼搜寻引擎技术”的话，那么不但可以发大财，而且几乎可以掌控世界，呵呵。

关于《长尾理论》的想法等我有时间了再详细介绍给大家，这次先让我谈谈有关OR Mapping的问题吧。

由于最近我在收尾ECO程序设计一书，正好写到有关ECO OR Mapping的内容，为了补充我个人在这方面的知识，因此我在Google上搜寻有关ECO OR Mapping相关的内容，有趣的是我看到了许多有关的讨论。许多人都关心ECO的OR Mapping技术，也非常有兴趣，有人甚至询问ECO的OR Mapping和Hibernate/NHibernate的比较，也有许多人担心ECO OR Mapping的透明性，以及如何在已有/旧的数据库模式和数据库数据上使用逆向工程产生封装类，但是又想在不改变已有/旧的数据库模式的状态下能够加上新的数据库数据表和封装类?

当然，对于这些问题也有许多人回答，提供了各种不同的答案。例如下面的一段话是我在某个有关OR Mapping的Blog中看到的：

我没有研究过NHibernate，不过我深入研究过ECO/ECOII，当然现在是ECOIII了。从设计目标上讲，ECO是非常优秀的，模型来自于UML，透明度极高，但是对数据库的控制度很低，这一点我不太能接受，因为完全照UML来设计数据库稍稍控制不好会导致一些严重的性能问题（我亲自经历过的案例)。我的目标仅仅是来自ER模型，设计时的透明度会有所降低，但对数据库的控制度比较高，并且既适宜新构建的系统又适宜已有数据库的系统甚至是异构的数据库系统。

我看了这段话之后我不太能理解作者说的ECO对于“数据库的控制度很低”是什么意思? 另外这段话又说“适宜已有数据库的系统甚至是异构的数据库系统”，我在想ECO也提供了这些功能啊。

另外我又常常看到下面的问题：

我知道直接从ECO model产生的table会有ECO_ID和ECO_TYPE等字段，请问要如何做才能享受用model修改的方便但又不变动原有数据库（可加新table）?

这个问题和第一位作者说的“适宜已有数据库的系统甚至是异构的数据库系统”有关，简单地说，是许多人在问ECO如何能够和现有存在的系统共存? 让开发人员能够在不影响旧有系统的数据情形下能够使用ECO技术开发后续的系统?

如果让我整理一下上面的问题，其实都是和ECO的OR Mapping有关，ECO不管是使用正向工程从业务逻辑模型自动产生数据库模式，或是从现有的数据库模式中以逆向工程产生封装类，开发人员都可以控制ECO的OR Mapping运作机制，其中的关键点就是ECO是一个RAD MDA工具，为了让开发人员快速使用MDA/DDA开发应用系统，因此，把OR Mapping做得非常自动化，让许多人误以为ECO的OR Mapping对于“数据库的控制度很低”，或是无法在现有的系统中结合ECO，因为ECO的OR Mapping会自己产生相关的数据库模式来运作。

其实ECO的OR Mapping可以像Hibernate/NHibernate使用XML来定义OR Mapping的规则，在ECO中这称为自定义 OR Mapping功能。开发人员可以在正向工程产生了数据库模式之后，结合FileMapperProvider和自定义 OR Mapping功能进行数据库的控制工作，而且开发人员在了解了ECO业务逻辑模型后，ECO内置上的OR Mapping机制，OCL转换SQL原理之后，甚至可以使用SQL来处理数据。

同样，在逆向工程方面也是如此，ECO的OR Mapping除了可以根据现有的数据库模式产生封装类之外，也允许开发人员自己在数据库中建立新的数据表，再借助ECO的设计器自动产生封装类，最后借助自定义 OR Mapping来定义新的数据表和新的封装类之间对映的关联，就像Hibernate/NHibernate一样。

为了让各位对于自定义 OR Mapping有概念，让我使用一个许多人都熟悉的范例，就是使用ECO的逆向工程从数据库产生封装类，接着再使用自定义 OR Mapping来增加新的数据表和新的封装类而不破坏已有的数据表和数据。这个范例使用InterBase的范例数据库employee.gdb来说明。

首先建立一个ECO ASP.NET项目，在FileMapperProvder中放入PersistentMapperBdp和连接到employee.gdb的BDP连接，接着在FileMapperProvder设计器中启动Wrap existing Database with Eco菜单以进行逆向工程，之后就会产生waORMappingDemoOrMapping.xml这个对映文件和如下的类架构：

例如现在我们就可以执行这个ECO ASP.NET应用程序，从下图中就可以看到ECO ASP.NET应用程序可以正确地使用面向对象的对象处理存在于employee.gdb之中的关联式数据了：

接着让我们关闭项目，然后自行在employee.gdb中建立一个新的数据表TestTable，如下：

由于在前面我们已经使用逆向工程建立了封装employee.gdb的类，而现在在employee.gdb中又新增了一个TestTable数据表，那么我们如何在不影响原来的数据情形下加入TestTable数据表到ECO的项目中？

这其实很简单，关键点是两个文件的内容，它们是定义封装类和数据库模式之间对映的规则的文件:waORMappingDemoOrMapping.xml。以及叙述逆向工程的整个模型:EmployeePackage.ecopkg。只要开发人员适当地处理这两个文件的内容就能够完成这项工作。

首先让我们处理对映的规则的文件：waORMappingDemoOrMapping.xml。这个文件就像Hibernate/NHibernate使用的对映配置XML文件一样，开发人员可以借助修改其中的内容来自定义ECO是如何对映封装类和数据表的。现在我们需要在waORMappingDemoOrMapping.xml中加入一个新的类，定义如下:

</KeyImpl>

</AliasDef>

</ClassDef>

一旦加入了这个类定义，ECO的OR Mapping就知道业务逻辑模型中存在了TestTable。

接着再于waORMappingDemoOrMapping.xml中加入下面叙述TestTable数据表模式的信息：

</Table>

一旦拥有了这两个定义，ECO就知道TestTable类是对映到TESTTABLE数据表。

现在我们需要让ECO的业务逻辑模型知道有了新的TestTable类的存在，所以我们可以在ECO类设计器中加入TestTable类，如下：

这个目的是让TestTable类能够正确地叙述在整个业务逻辑模型的文件EmployeePackage.ecopkg之中。

完成了这些操作之后，再次执行范例应用程序，我们就可以看到如下图所示的画面：

TestTable果然正式加入了我们的业务逻辑模型，而且我们的确可以在ECO ASP.NET应用程序中处理这个数据表的数据：

当然，开发人员也可以在这个借助逆向工程产生的ECO ASP.NET应用程序中使用SQL来处理原有的数据，它的透明度和任何传统的数据库应用程序是一样的。