原来一直使用代码生成包括CodeSmith和CodeMatic最近打算系统学习一下Nhibernate经过简单的一点探索发现ORM和代码生成真是个有千秋
本文侧重比较一下ORM和代码生成二者的优缺点让二者华山一比高下目的为去伪存真使二者能够相辅相成从而更好的提高开发效率
本文从下面三个层面对ORM（以NHibernate为首发的O阵营） 和代码生成（以CodeMatic为首发的C阵营）进行比较
）针对数据库二者的架构层次上的异同
） 针对应用程序二者在使用和配置上的异同
） 针对业务逻辑二者在对变化和复杂度上支持度的异同
下面就具体针对这三个层面做一下具体分析这些分析都来源于自己开发中的一些经验和心得有些是正确的有些也存在这样那样的问题写出来希望的也只是能抛砖引玉得到更多朋友兄弟的帮助和支持
） 针对数据库二者在架构层次上异同
首先看一下下面这张图
ORM针对数据库是由上而下的关系也就是说ORM并不依赖于数据库他可以完全从关系数据库中将程序员解放出来需要程序员小心呵护的是传递给nhibernate的persistent object这看起来更加OO而代码生成恰恰相反代码生成依赖于关系数据库它总结数据库操作的一些共性将本来需要程序员手写的代码自动生成出来从OO的角度来说代码生成的过程并不体现OO思想但根据模版或者软件作者的一些逻辑生成出来的代码却可能具有很好的OO思想针对数据库来说ORM是自顶向下的代码生成则是自下而上二者方向恰好相反
）针对应用程序二者在使用和配置上的异同nhinernate的使用需要在原有系统上添加对nhibernatedll和其他一些相关的dll的引用而代码生成则不然代码生成是在另外的一个软件中通过指定数据库来生成用于操作数据库的文件将这些文件添加到项目中的时候才可以正常使用nhibernate最让人头疼的就是配置和映射文件的编写而代码生成如果需要完成复杂的逻辑和自定义的业务需要编写CodeSmith等软件的模版这些模版的编写也不是一件简单的事情从使用和配置上看二者的异同在于使用方法引用方法配置文件nhibernate系统内需要添加相关引用需要编写大量的配置和映射文件codematic系统外不需要添加引用业务简单时不需要配置复杂时需要编写自定义模版
）针对业务逻辑二者在对变化和复杂度上支持度的异同
假如原有一个User表这个表已经运行了一段时间但目前需要在User表里面添加一个可为null的字段BirthDay二者对此需求的响应各自是应该是怎么样的呢？
数据库改动 配置改动 代码更改nhibernate 无需 需要映射文件中添加对BirthDay的映射 更改User类添加属性BirthDaycodematic 需要在User表里面添加一个BirthDay字段 不需要更改 最佳使用状态下需要从数据层到业务逻辑层重新生成代码如果以前有改动则需要手动添加BirthDay向伽相关代码针对于单表操作二者都比较简单但是当业务变得复杂的时候二者在表现力如何呢？比如现在有这样一种应用环境计算和维护职员和工资
需求
）列出所有职员
）列出某个职员的某月的工资信息
） 统计某个员工在第个季度的总工资
）计算上半年公司支付给员工的总工资其中包括已离职人员的工资
在这样一种应用环境下分别讨论二者如何应付数据表 业务对象 配置文件 业务对象的使用nhibernate 无需创建 手动编写UserSalary业务对象 需要编写配置文件标示业务对象的主从关系 在二者差生围度和关联时内置支持codematic 需要创建User和Salary表并指定主从 不需 不需 产生关联和围度时需要手工更改数据底层和上层业务代码
总结ORM和代码生成二者各有各自的好处但综合考虑ORM更符合OO的口味而代码生成则比较灵活可以应用到除了数据库操作的其他方面比如生成nhibernate需要的映射文件等加上原有的URM和数据建模几者共用开发效率一定会有较大的提高
