对使用CodeSmith模板生成NHibernate的代码的分析

       CodeSmith是我们常用的代码生成工具，其跟据不同的模板生成不同代码的方式能大大加快我们的项目开发，减少重复劳动。NHibernate模板就是其常用模板之一。从这里可以下载到最新的模板文件。现在最新的版本为NHibernate-v1.2.1.2125，可以生成NHibernate1.2，2.1，3.0的代码。我下载的稍早，是NHibernate-v1.1.7.2056，最高生成2.1的代码，不过大同小异，就以我下载的版本来进行分析吧。

      基本生成操作就不说了，官网上有讲解的视频，也有大把的网友做了专门的教程。代码生成后，主要分为五大块：

      1.Base块，也就是基类块，这里放有BusinessObjects块，ManagerObjects块，UnitTests块的基类，还包括一个作者提供我们的一个管理NH的ISession的小模块：NHibernateSessionManage块。

      2.BusinessObjects块,也就是我们常说的实体(Entity/Model)块。里面放置着与数据库表一一对应的各个实体。

      3.HbmMaps块，NH必用，不多讲。

      4.ManagerObjects块，也就是我们常说的BL层，里面包括了对每个实体的操作类，命名方式类似于XXXManage等等。另外还有一个小工厂，通过不同的方法实例化不同的管理类，比较简单，不表。

      5.UnitTests块，测试用例块，这不是我们今天谈的重点，故不多述。

      从上面可以看到，NH模板生成的代码是典型的三层架构式代码，采用的架构模式是活动记录式。 更详细的概念描述请自行Google，或者参见我另两遍博文：业务逻辑架构模式(事务脚本，表模块，活动记录，领域模型)，再谈业务逻辑架构模式(事务脚本，表模块，活动记录，领域模型)。

      由于Base块里面的基类与下面三块里的子类的关系较大，所以我将按照BusinessObjects块，ManagerObjects块，NHibernateSessionManage块的顺序来讲述，在讲述的过程中直接将基类一起表述。例子就参见下面的一张图，其中Aim是实体类，AimManage是其对应的管理类。

      首先是BusinessObjects块，其实我们更常见的叫法是实体层。Aim是我们自己的实体，BusinessBase<T>是其基类，其中T这个泛型是指主键的类型，如果是联合主键，这里则不会是基本类型，而是会单独生成一个类，这个类的属性与联合主键的每一个子元素一一对应。BusinessBase<T>实现了IBusinessBase<T>接口，在这个接口里规定了一个很重要的属性：Id，其类型由T来指定，这表明了所有表的主键的在代码里都叫Id。当然，如果实际的表中的主键不叫Id也是没有关系的，实体的配置文件hbm.xml可以解决这个问题。这个接口还有两个方式：GetHashCode和Equals，比较简单，不多表。

      再来看ManagerObjects块，对于这我们也有更常见的叫法：BL层或者是业务逻辑层。

      从上向下讲，最开始是个IManagerBase<T, TKey>接口，其中T是指其管理的实体类别，TKey是其管理的实体的主键类型。在这个接口中定义了常见的实体操作方式：增删改和各种形势的通用的查询。ManagerBase<T, TKey>类则是其具体的实现。IAimManage是具体实体管理类的接口，里面定义了具体实体所具有的特定的操作方法，注意，这里继承了IManagerBase<T, TKey>接口，这是很重要的一点，等下表述。最后是AimManage类，其继承了ManagerBase<T, TKey>类和IAimManage接口。从前者获取通用操作的实体，从后者获取定义的特定操作并由自己来实现。这里就要讲为什么IAimManage接口要继承IManagerBase<T, TKey>。从编译的角度来讲，前者不继承后者依然可以通过编译，但从我们架构代码的角度来讲，当编码中我们要操作AimManage类时，有两种方式，一种是直接通过本类型操作：

一种是通过接口操作：

为了减少代码耦合，通过接口操作是比较理想的方式。如果前者不继承后者，当出现后者的代码时，我们就无法通过manage来操作AimManage类从ManagerBase<T, TKey>类继承到的通用操作了。换种说法，由于ManagerBase<T, TKey>类继承并实现了IManagerBase<T, TKey>接口，AimManage类又继承了ManagerBase<T, TKey>类，那么实际上AimManage类间接继承并实现了IManagerBase<T, TKey>接口。现在AimManage类又继承并实现了IAimManage接口，从多继承的角度来讲，各个接口只能操作其子类从本接口继承而来的属性与方法，如下图：

如果IAimManage接口没有继承IManagerBase接口，那当代码是这么写的时候：

变量manage是无法执行A()方法的，因为A()方法从IManagerBase接口而来。

      最后看看NHibernateSessionManage块，这是作者为我们提供的一个Session管理模块，包括两个类与两个接口。这个模块通过接口的方式与其它模块交互的少，故不多表，主要讲讲两个类的使用：NHibernateSessionManager类与NHibernateSession类。NHibernateSession类是作者为我们重新封装的Session类，他将始的ISession接口封装了进去，目的是代替NH原始的ISession接口。里面有两个重要的成员ISession和ITransaction。其中ISession就是NH的原始的ISession接口。由于他在这里将原始的ISession接口封装了进去，通过其操作事务就不是很方便，于是作者就使用成员ITransaction将ISession内的ITransaction引用出来，并写了一大堆方法来完成对事务的操作。还有一个方法：GetISession()来获取原始的ISession。

      NHibernateSessionManager类是具体的Session管理类。他通过静态变量Instance实现了单例模式。他有一个重要的属性Session和一个重要的方法CreateISession()。通过Session属性来获取本次操作的NHibernateSession类。可以看到，作者将每次操作的NHibernateSession放到了缓存中(webForm与winForm放置的地方不同)，提高了性能。CreateISession()方法则是真正获取原始ISession的方法，NHibernateSession类的GetISession()方法调用的也是他。

       回到ManagerBase<T, TKey>类，在其两个构造函数中：

       默认就是调用NHibernateSessionManager类单例实例的Session属性，或者通过自定义INHibernateSession来注入。

      以上就是代码分析的全过程，可以看出，生成的代码精干紧凑，使用方便，是我们学习三层架构模式，活动记录模式和生产实践的良好示范。