O/R Mapping 的故事续集

记得在温老先生的《程序设计心理学》里，好像有对程序的功能和性能进行过深入的探讨，比如一些艺术家级的程序员为了实现一个性能完美的Hello World程序，花费了别人本来可以用来编写一个应用服务器的时间。然而，当我们的程序规模大到一定程度，终究有一天要考虑性能问题。事实上在一些对性能要求高的应用程序中，在最初的设计中就必须为性能埋下很好的伏笔。

人们对ASP.Net提出的质疑中，有这样一种论调，就是现在的不少工具在为程序员提供便利的同时，却牺牲了最终用户的使用体验。事实上O/R Mapping也是类似，它能跨越两种不同的编程模型，让程序员用熟悉的OO编程方式来操作关系数据库，却让数据在出入数据库的时候，都必须通过一个包含着各种繁琐耗时的动态映射的数据持久层。同样也因为使用了动态映射，在前文中XObject和XPath的取舍之间，如果加上性能的考虑，问题也会变得更加复杂。幸运的是，并非所有的场景都会对性能有如此高的要求，硬件的不断发展也成为我们在性能设计上节省成本的很好借口。然而数据库的访问，自古以来都是OLTP系统最常见的性能瓶颈。尤其对于那些需要同时支持上万个终端的WEB应用，如何在功能、性能和开发效率之间取得平衡，的确是一个高深的工程难题。在这样的应用中，如果广泛使用O/R Mapping，可能就需要在硬件上投入更大的成本来弥补动态类型机制带来的性能损失。我想一些后关系数据库所标榜的性能优势，可能大部分都应该得益于从存储到编程都采用了统一的OO模型，而几乎不需要在Mapping上花费太多代价。遗憾的是，在目前我们所处的环境里，后关系数据库还远远没有成为主流。

在后关系数据库没有来临的日子里，代码自动生成的方案（比如CodeSmith+NTier）似乎也能很好地解决动态映射的问题。它把数据库中的每个表映射成一个实体类（Entity）和一个控制类（Provider），字段就映射成实体类的属性，增删查改的动作就映射成控制类的方法。如果有自定义的存储过程，你可以在控制类上增加一个方法进行封装。实际上CodeSmith会帮你自动生成所有可以从数据库直接映射过来的静态代码，相当于把传统O/R Mapping提供的运行期动态机制重新移回编译期，里面还包含了众多的设计模式和微软社区里面提供的Best Practise，最终组成一个比较完整的数据访问层。除了CodeSmith以外目前还有不少代码自动生成的工具，没有时间去仔细研究，但CodeSmith提供的一种类似ASP.Net生成HTML的方式来生成代码的方法，甚至还支持Code Behind，第一次看到的时候的确让人眼前一亮。ASP.Net的确是个有趣的框架，哪怕是使用ASP.Net的宿主，通过它提供的那几个基础接口，可能也可以做出很多有趣的扩展。

除了性能之外，O/R Mapping的另外一个缺点就是不能动态改变数据库结构。比如数据库增加了一个字段，我们需要在类中增加一个成员的定义，或者让CodeSmith重新生成一下代码，然后重新编译。为了解决这个问题，一些中间件公司在它们的产品中就用XML来定义数据库的Schema，然后整个从数据库到数据访问层到业务逻辑和界面表现都基于这个Schema来生成或者运作，它们的程序对任何的表、字段甚至类型都一视同仁，O/R Mapping提供的强类型对象在这种编程模型上也变得毫无意义了。于是我们就可以看到，如果要在客户信息里面增加一个Email字段，我们只需要做简单的配置，然后从输入客户信息的Windows界面到WEB上的客户一览表都同时增加了一个EMAIL字段，同时更新的还有数据库中的客户信息表以及相关的存储过程。

将这些动态机制用到及至，也许会彻底改变如今软件行业的面貌。这在目前一些软件里面已经可以初见端倪，用户甚至可以用一个向导来生成小型的MIS系统。将来更多的代码将被自动生成，加上编译器的轻量化，如今程序员所做的一部分低智能的工作将完全被机器取代，甚至还可能制造出能自己更新自己的应用程序。行业背景又不得不把我导向一个蹩脚的生物学比喻。现在的软件系统更象是停留在低等的病毒时代，我们暂不讨论它的感染和繁殖，它在体外就是一个僵硬的蛋白质外壳，压根不象个生命体。未来的软件应该进入细胞时代，有自己的核糖体，根据业务逻辑来制造它所需要的蛋白质，简单地说就是把编译器集成到常规的应用软件中，让它自己具有更新自己的能力。未来的未来，可能会经历由单细胞变成多细胞，并衍生出干细胞到各种功能特化细胞的过程。

其实我很不喜欢这些蹩脚的比喻，显得如此幼稚而且外行看来简直就是故弄玄虚。下面简单地总结一下想象中下一代软件系统的几个基本组件，就算未来世界不一定是如此设计，但至少可以从一个技术侧面反映了软件行业的运作规则。现在其他三个基本组件都已经比较成熟了，最难的就是让机器获得需求（Generator）以生成可执行的程序代码（Executer）的部分，也就是现在程序员的日常工作。