Nhibernate分析之华山论剑篇

    原来一直使用代码生成，包括CodeSmith和天平兄的CodeMatic。最近打算系统学习一下Nhibernate，经过简单的一点探索，发现ORM和代码生成真是个有千秋。本文侧重比较一下ORM和代码生成二者的优缺点，让二者华山一比高下，目的为去伪存真，使二者能够相辅相成。从而更好的提高开发效率。
    本文从下面三个层面对ORM（以NHibernate为首发的O阵营) 和代码生成(以CodeMatic为首发的C阵营)进行比较：
 1）针对数据库二者的架构层次上的异同
 2)  针对应用程序二者在使用和配置上的异同
 3)  针对业务逻辑二者在对变化和复杂度上支持度的异同。
   下面就具体针对这三个层面做一下具体分析，这些分析都来源于自己开发中的一些经验和心得，有些是正确的，有些也存在这样那样的问题。写出来，希望的也只是能抛砖引玉，得到更多朋友，兄弟的帮助和支持。
1) 针对数据库二者在架构层次上异同
首先看一下下面这张图：

ORM针对数据库是由上而下的关系，也就是说ORM并不依赖于数据库。他可以完全从关系数据库中将程序员解放出来，需要程序员小心呵护的是传递给nhibernate的persistent object。这看起来更加OO，而代码生成恰恰相反，代码生成依赖于关系数据库。它总结数据库操作的一些共性，将本来需要程序员手写的代码自动生成出来。从OO的角度来说，代码生成的过程并不体现OO思想，但根据模版或者软件作者的一些逻辑。生成出来的代码却可能具有很好的OO思想。针对数据库来说，ORM是自顶向下的，代码生成则是自下而上。二者方向恰好相反。
2）针对应用程序二者在使用和配置上的异同
nhinernate的使用需要在原有系统上添加对nhibernate.dll和其他一些相关的dll的引用，而代码生成则不然，代码生成是在另外的一个软件中，通过指定数据库来生成用于操作数据库的文件，将这些文件添加到项目中的时候才可以正常使用。nhibernate最让人头疼的就是配置和映射文件的编写。而代码生成，如果需要完成复杂的逻辑和自定义的业务，需要编写CodeSmith等软件的模版，这些模版的编写也不是一件简单的事情。从使用和配置上看，二者的异同在于

	使用方法	引用方法	配置文件
nhibernate	系统内	需要添加相关引用	需要编写大量的配置和映射文件。
codematic	系统外	不需要添加引用	业务简单时不需要配置，复杂时需要编写自定义模版

3）针对业务逻辑二者在对变化和复杂度上支持度的异同
  假如原有一个User表，这个表已经运行了一段时间。但目前需要在User表里面添加一个可为null的字段:BirthDay,二者对此需求的响应各自是应该是怎么样的呢？

	数据库改动	配置改动	代码更改
nhibernate	无需	需要映射文件中添加对BirthDay的映射	更改User类，添加属性BirthDay
codematic	需要在User表里面添加一个BirthDay字段	不需要更改	最佳使用状态下需要从数据层到业务逻辑层重新生成代码，如果以前有改动，则需要手动添加BirthDay向伽相关代码

针对于单表操作，二者都比较简单，但是当业务变得复杂的时候，二者在表现力如何呢？比如现在有这样一种应用环境，计算和维护职员和工资，需求：1）列出所有职员 2）列出某个职员的某月的工资信息 3) 统计某个员工在第2个季度的总工资。4）计算上半年公司支付给员工的总工资。其中包括已离职人员的工资。
在这样一种应用环境下，分别讨论二者如何应付

	数据表	业务对象	配置文件	业务对象的使用
nhibernate	无需创建	手动编写User,Salary业务对象。	需要编写配置文件，标示业务对象的主从关系	在二者差生围度和关联时，内置支持
codematic	需要创建User和Salary表，并指定主从	不需	不需	产生关联和围度时，需要手工更改数据底层和上层业务代码

   总结，ORM和代码生成二者各有各自的好处，但综合考虑ORM更符合OO的口味，而代码生成则比较灵活，可以应用到除了数据库操作的其他方面。比如生成nhibernate需要的映射文件等。加上原有的URM和数据建模，几者共用，开发效率一定会有较大的提高。