Hibernate实战_笔记4（ORM概念）

      现在我们来简单地看看可以由Java应用程序实现持久层的各种方法。别着急，我们很快就要讲到ORM和Hibernate了。通过看看其他方法，可以学到很多东西。

用SQL/JDBC手工编写持久层

      对于应用程序员来说，处理Java持久化最常用的方法是直接使用SQL和JDBC。毕竟，开发人员熟悉关系数据库管理系统，他们理解SQL，并且知道如何使用表和外键。此外，他们始终可以使用众所周知且被广泛使用的DAO模式，来隐藏业务逻辑中复杂的JDBC代码和不可移植的SQL。
DAO是个很好的模式——因此我们甚至经常推荐把它与ORM一起使用。然而，给每个领域类手工编写持久化代码涉及的工作量相当大，特别当支持多个SQL方言的时候。这项工作通常消耗很大一部分开发精力。甚至，当需求改变时，手工编写的解决方案总是需要更多的注意力和维护精力。

为什么不实现一个简单的映射框架来适应项目的特殊需求呢？这种努力的结果甚至可以在未来的项目中重用。许多开发人员已经采用了这种方法 ；如今许多自制的对象/关系持久层应用于产品系统中。但是我们不推荐这种方法。优秀的解决方案已经存在：不仅有商业供应商销售的工具（非常昂贵），也有免许可的开源项目。我们确信你肯定能够找到一种满足你需求的解决方案，包括业务需要和技术需求。这种解决方案可能比你在有限的时间内能够创建的解决方案完成更多的工作，并且做得更好。

面向对象的数据库系统

      由于我们是在Java中使用对象，所以如果有一种方法 能把那些对象存储到数据库中，又根本不必扭曲对象模型就好了。在20世纪90年代中期，面向对象的数据库系统备受关注。它们以一个网络数据模型为基础，在关系型数据模型出现之前的十几年前，这种方法很普遍。基本的思想是存储一个对象网络，包括它所有的指针和节点，并随后重新创建相同的内存图。这可以用各种元数据和配置设置进行优化。
      与其说是像外部数据仓库，面向对象的数据库管理系统（OODBMS）则更像是应用程序环境的一个扩展。
我们不想深入研究为什么面向对象的数据库技术还没有流行起来；我们将发现对象数据库还没有被广泛采用，可能近期内也不会。考虑到当前的政治现实（预先确定的部署环境）和数据独立的普遍需求，我们相信压倒多数的开发人员会有更多的机会使用关系技术。

什么是ORM

简而言之，ORM就是利用描述对象和数据库之间映射的元数据，自动（且透明）地把Java应用程序中的对象持久化到关系数据库中的表。
ORM解决方案包含下面的4个部分：
1、在持久化类的对象上执行基本的CRUD操作的一个API；
2、用于指定引用类或者类属性的查询的一种语言或者API；
3、用于指定映射元数据的一种工具；
4、用于实现ORM的一项技术，与事务对象交互，执行脏检查（dirty checking）、延迟关联抓取以及其他优化功能；

来看一下可以实现ORM的各种方法。Mark Fussel（Fussel，1997），ORM领域的一位开发人员，定义了下列4个ORM质量等级。

1、纯关系

      整个应用程序（包括用户界面）都围绕着关系模型和基于SQL的关系操作而设计。这种方法，除了它不足以用于大型系统之外，对于那些容许低级代码重用的简单应用程序来说，它不失为一种极好的解决方案。直接的SQL可以在各个方面调优，但是缺点（例如缺乏可移植性和可维护性）也是很显著的，尤其对长期运行而言。这类应用程序经常大量地使用存储过程，把一些工作从业务层转换到了数据库中。

2、轻量对象映射

      实体被表示为手工映射到关系表的类。使用众所周知的设计模式，把手工编码的SQL/JDBC从业务逻辑中隐藏起来。这种方法非常普遍，对于那些带有少量实体的应用程序，或者那些使用普通的元数据驱动的数据模型的应用程序来说，它是很成功的。存储过程在这种类型的应用程序中可能也有一席之地。

3、中等对象映射

      这种应用程序围绕对象模型而设计。SQL使用一个代码生成的工具在创建时产生，或者通过框架代码在运行时产生。对象之间的关联得到持久化机制的支持，并且查询可能使用一种面向对象的表达式语言来指定。对象由持久层高速缓存。ORM产品和自制的持久层都至少支持这一级别的功能。它非常适合一些复杂事务的中等规模的应用程序，特别是在不同的数据库产品之间的可移植性很重要的时候。这些应用程序通常不使用存储过程。

4、完全对象映射

      完全的对象映射支持完善的对象模型：组合、继承、多态和可达的持久化。持久层实现透明的持久化；持久化类不必继承任何特殊的基类，或者实现特殊的接口。高效的抓取策略（延迟、即时和预取）和高速缓存策略被透明地实现到应用程序。这一级别的功能无法通过自制的持久层实现——它相当于几年的开发时间。许多商业和开源的Java ORM工具已经实现了这个质量等级。

为什么选择ORM

      ORM的实现非常复杂——虽然没有应用程序服务器复杂，却比Web应用程序框架如Struts或Tapestry要复杂得多。为什么要把另一个复杂的基础元素引入到我们的系统中呢？值得这么值吗？
      ORM一个假定的益处是使开发人员避免杂乱的SQL。持这种观点的人认为不能期待面向对象的开发人员很好地理解SQL或者关系数据库，并且他们认为SQL有点讨厌。正好相反，我们认为Java开发人员必须足够熟悉并欣赏关系模型和SQL，以便用ORM进行工作。ORM是一项高级的技术，将被为其付出艰辛努力的开发人员所用。要有效地使用Hibernate，必须能够观察和解读它生成的SQL语句，并理解对于其性能的含义。
现在，来看看ORM和Hibernate的一些益处。

1、生产力

      与持久化相关的代码可能会是Java应用程序中最冗长乏味的代码。Hibernate去除了许多琐碎的工作，并让你把业务集中在业务问题上。
无论你喜欢哪种应用程序开发策略——自顶向下，从一个领域模型开始；或者自底向上，从一个现有的数据库Schema开始——Hibernate与适当的工具一起使用，将明显减少开发时间。

2、可维护性

      更少的代码行（LOC）使得系统更易于理解，因为它强调业务逻辑甚于那些费力的基础性工作。
然而，Hibernate应用程序更易维护还有其他原因。在手工编码的持久化系统中，关系表示法和对象模型实现领域之间存在着一种必然的压力。改变一个，通常都要改变另一个，并且一个表示法设计经常需要妥协以便适应另一个的存在。（在实际应用程序中，通常是领域的对象模型发生妥协。）ORM提供了两个模型之间的一个缓冲，允许面向对象在Java方面进行更优雅的利用，并且每个模型的微小变化都不会传递到另一个模型。

3、性能

      一种普通的断言是，手工编码的持久化与自动的持久化相比总是至少可以一样快，并且经常更快。这是真的，就像汇编代码总是至少可以与Java代码一样快，或者手工编写的解析器总是至少可以与由YACC或者ANTLR产生的解析器一样快，这同样是真的一样——换句话说，这有点离题了。这种断言的言下之意是，手工编码的持久化在实际应用程序中将至少完成得一样好。但是，这种含意只有当实现至少一样快的手工编码的持久化所需的努力，类似于使用自动的解决方案所付出的努力时才是对的。真正值得关注的问题是，当我们考虑到时间和预算的约束时会发生什么？