动机

　　曾经使用许多方法在数据库和目标代码之间传输数据。从手动编码的SQL到JDO，然后再到EJB，我从未找到一种特别喜欢的方法。自从采用测试驱动开发（TDD）作为指导原则以来，这种不满情绪变得更加强烈。

　　单元测试的障碍应尽可能少。在关系数据库中，障碍的范围从外部依赖（数据库在运行吗？）到保持关系模型和对象模型同步的速度。由于这些原因，保持数据库访问代码与核心对象模型分离且无需涉及真实数据库而进行尽可能多的测试是很重要的。

　　通常这会导致我们进入下面两种模式之一。第一种是具体化所有访问域对象的数据以及数据与单独类或接口之间的关系。这就是典型的能够检索、编辑、删除和添加域实体的数据存储对象。这在单元测试中是最容易模拟出来的，但趋向于把域模型对象作为不带有任何关系行为的纯数据对象。直接从父对象访问子记录是最理想的，而不是将父对象处理为第三方类来决定子记录。

　　其他方法已经使访问接口的域对象进入数据映射层（一种la Martin Fowler的数据映象模式）。这具有推动域模型中的对象关系的优点，在域模型中，对象关系型接口只需表达一次即可。使用域模型的类不支持持久性机制，因为它本身内在化到域模型中。这使代码集中在设法解决的业务问题，而很少关注对象关系型映射机制。

　　我的当前项目涉及到处理大量的棒球统计数据，并使用这些数据进行模拟。因为数据已经在关系数据库中，所以对于我来说，有机会开发Hibernate对象关系型映射系统。我曾对Hibernate有很深刻的印象，但我遇到的一个问题是，在使用Hibernate进行单元测试的数据映射时，设法插入一个间接层。该附加层非常脆弱，编写起来感到非常困难。实际部署版本简单地通过了特定于Hibernate的实现。更坏的情况是，模拟版本比真正的“产品级”版本更复杂，只因为模拟版本里没有基本对象存储器和带有Hibernate的映射。

　　我也使用很多复杂的Hibernate查询，想要对应用程序的重要部分进行单元测试。然而，对活动的数据库进行测试不是好主意，因为这几乎总是产生维护问题。另外，由于测试最好互相独立，在测试上下文数据中使用相同的主键意味着必须在每次测试前创建代码来清理数据库，当涉及到大量关系时就成为一个实际问题。

　　通过使用HSQLDB和Hibernate强大的模式生成工具，能够对应用程序映射层进行单元测试，并在对象查询中找到不计其数的bug，这在以前手工测试时是做不到的。利用下面的技术概述，可以在开发过程中对整个应用程序进行测试，并且在测试有效区域内没有损害。