4.NHibernate 基本整合

   在开发应用程序时，我的目标是：
  • 写一次代码，并且只有一次
  • 代码的简单化和可读性
  • 最小程度的维护耦合和依赖
  • 保证关注点之间完全分离
  • 使用测试驱动开发来完成上面所有目标。
    这一章讨论，使用这些设计原理来把NHibernate整合到ASP.NET应用程序里。通过解剖Basic NHibernate 例子，我们就可以完成这些。

    构架备注

    这个基本示例不能被看成ASP.NET应用程序一个可以重新再度使用的构架，这一点非常必要。这个示例应用程序里的重点就是：以一种简单且明了的方式显示NHibernate整合。如果你在寻找“现实世界早已定制的”结构体系，看完这部分后，一定要记得阅读Extending the Basics to an "Enterprise" Solution。这个简单的示例确实介绍了一些最优方法技术和设计模式。
    分离接口

    分离接口,也就是依赖倒置，是在应用层之间建立一个完全分离的技术。Martin Fowler 和Object Mentor描述过这种技术，在Robert Martin的 Agile Software Development中有更清楚的描述。这种技术通常被用于清晰地将领域层与数据访问层去分开来。例如：假设一个客户对象－在领域层－需要与数据访问对象通信，以此重新找回一些过去的指令。（不管是不是在领域层，其它讨论中会有直接与DOA通信。）因此，客户对象在订单数据访问对象有一个从属器－在数据层。但是对于使用订单数据访问对象来返回命令，数据访问对象要求有一个倒置返回到领域层。

   最简单的解决方案就是把数据层（包括DAOs）放在同一个物理组件里，作为领域层。为了维护一个虚拟分离关注点,包含的项目包含2个文件夹，一个被称为域名，另一个被称为数据。（事实上，在以前的生活中，我在一个good-sized项目上使用了这一方法，产生了一些后悔的后果。）这个方法带来一些不好的后果。

   • 领域层和数据层双向依赖
   • 没有什么能阻止数据层流向领域层，反之亦然。如果在结构上它不能被阻止，那么它就会发生。
   • 不使用现场数据库来支持数据层，很难把单元测试领域层。在其他缺点之间，这个使得单元测试性能萎缩，因此，开发者停止了单元测试。

    相对应地，域名和数据层可以放在物理上分开的组件中；例如：分别放在Project.Core and Project.Data上。领域层（Project.Core组件）包括域名对象和DAO接口。数据层（Project.Data组件）包括DAO接口（定义在领域层）具体的实施方式。在下面的两个程序的集合图中有表示。注意箭头代表数据层到领域层的单向依赖。

    这个完整分离带来了很多好处：
    • 在结构上，开发人员不会在领域层直接使用具体的数据访问代码，当没有增加大量容易混乱的引用情况下。如NHibernate或者System.Data.SqlClient.
    • 这个领域层仍然无视数据层是怎样通信，或者与谁通信。因此，没必要修改领域层，确更容易找到数据访问执行的细节（例如：从ADO.NET到NHibernate）。
   • 在单元测试时，因为依赖于接口，就很容易给领域层提供一个“伪造”的数据访问层。这样可以保证单元测试快速运行并且不需要维护数据库中的测试数据。
在示例应用程序中包含了分离接口的执行例子，下面将进一步讨论。