一. ORM简介
对象关系映射模式是一种为了解决面向对象和存在于关系数据库中的互不匹配的技术。 简单地说，ORM通过使用描述对象和数据库之间的映射的元数据，自动将程序中的对象持久化到关系数据库中。 那么，到底如何实现可持续化呢？ 一个简单的方法是采用硬编码方法为所有可能的数据库访问操作提供单独的方法。
该方案存在以下不足：
1 .持续化层缺乏弹性。 业务需求发生变化时，需要修改持久化层的接口
2 .持久化层同时绑定到域模型和关系数据库模型，无论域模型还是关系数据库模型发生变化，都毒害了持久化之前的相关程序代码，增加了软件的维护难度。
ORM提供了实现持久层的另一种模式，利用映射元数据描述对象关系的映射，使ORM中间件能够在哪个APP的业务逻辑层和数据库层之间架起桥梁。 Java的典型ORM中间件是：Hibernate、ibatis和speedframework。
ORM的方法论基于三个核心原则：
简单：以最基本的形式对数据进行建模。
传递性：数据库结构以任何人都能理解的语言记录。
精度：根据数据模型建立正确标准化的结构。
二. ORM的概念
从信用证开始吧。 o从“对象”(Object )开始，而r来自“关系”(relations )。 大多数程序都存在对象和关系数据库。 在业务逻辑层和用户界面层，我们是面向对象的。 当对象的信息发生变化时，需要将对象的信息保存在关系数据库中。
当豁达的海豚开发APP应用程序(不使用O/R Mapping )时，它们可能会编写大量用于存储、删除和从数据库中读取对象信息的数据访问层代码。 你在DAL上写了很多方法来读取对象的数据，或者改变状态的对象。 这些代码总是重复写的。
ORM解决的主要问题是对象关系的映射。 域模型和关系模型分别基于概念模型。 域模型是面向对象的，而关系模型是面向关系的。 通常，持久化类对应于表，类的每个实例对应于表中的一条记录，而类的每个属性对应于表中的每个字段。
ORM的技术特征：
1 .开发效率提高了。 ORM可以自动将Entity对象和数据库中的Table映射到字段和属性，因此可能不需要专用的大数据访问层。
2.ORM提供到数据库的映射，无需用sql直接编码，就可以像操作对象一样从数据库中检索数据。
三. ORM的优缺点
ORM的缺点是牺牲程序的执行效率和思考模式。
在系统结构上，采用ORM的系统一般为多层系统，系统层次越多效率越低。 ORM是一种完整的面向对象方法，面向对象的方法也会影响性能。
我们开发系统时，一般都有性能问题。 性能问题主要是由于算法不正确和数据库使用不正确造成的。 ORM生成的代码一般不能编写有效的算法，在数据库APP应用中很可能被误用，主要体现在持久对象的提取和数据的加工处理上。 使用ORM时，程序员很可能会将所有数据提取到内存对象中，然后进行过滤和加工处理，容易出现性能问题。
当使对象持久化时，ORM通常会持久化所有属性。 在某些情况下，这是不可取的。
但是，ORM是工具，工具确实可以解决一些重复、简单的劳动。 这是不可否认的。 但是，不能期待工具能一举解决所有问题。 有些问题还是需要特别处理的，但需要特别处理的部分对于大多数系统应该很少。
什么是ORM？ 为什么要用ORM？ 什么是“永久化”
持久性是指将数据(如内存中的对象)存储在可持久存储设备(如磁盘)上。 持久化的主要APP是将内存中的数据存储在关系数据库中。 当然，也可以存储在磁盘文件或XML数据文件等中。
持久层是什么
持久层是专门用于实现数据持久化的APP应用领域的特定系统的逻辑方面，用于将数据用户与数据实体相关联。
什么是ORM
换句话说，Object-Relationl Mapping负责在关系数据库和对象之间进行映射。 这样，在具体操作数据库时，就不必与复杂的SQL语句进行交互，只需像处理对象一样进行操作即可。
为什么要进行持续化和ORM设计(
在当前的企业APP应用系统设计中，MVC (模型视图控制)是主要的系统体系结构模型。 MVC的模型包括复杂的业务和数据逻辑以及数据访问机制，如连接JDBC、SQL生成和语句创建以及读取ResultSet结果集。 将这些复杂的业务逻辑和数据逻辑分离，将系统的紧密耦合关系转换为松耦合关系，即解除耦合，就是降低系统的耦合度
切要做的，也是持久化要做的工作。MVC 模式实现了架构上将表现层（即View）和数据处理层（即Model）分离的解耦合，而持久化的设计则实现了数据处理层内部的业务逻辑和数据逻辑分离的解耦合。而 ORM 作为持久化设计中的最重要也最复杂的技术，也是目前业界热点技术。简单来说，按通常的系统设计，使用 JDBC 操作数据库，业务处理逻辑和数据存取逻辑是混杂在一起的。
一般基本都是如下几个步骤：
1、建立数据库连接，获得 Connection 对象。
2、根据用户的输入组装查询 SQL 语句。
3、根据 SQL 语句建立 Statement 对象 或者 PreparedStatement 对象。
4、用 Connection 对象执行 SQL语句，获得结果集 ResultSet 对象。
5、然后一条一条读取结果集 ResultSet 对象中的数据。
6、根据读取到的数据，按特定的业务逻辑进行计算。
7、根据计算得到的结果再组装更新 SQL 语句。
8、再使用 Connection 对象执行更新 SQL 语句，以更新数据库中的数据。
7、最后依次关闭各个 Statement 对象和 Connection 对象。
由上可看出代码逻辑非常复杂，这还不包括某条语句执行失败的处理逻辑。其中的业务处理逻辑和数据存取逻辑完全混杂在一块。而一个完整的系统要包含成千上万个这样重复的而又混杂的处理过程，假如要对其中某些业务逻辑或者一些相关联的业务流程做修改，要改动的代码量将不可想象。另一方面，假如要换数据库产品或者运行环境也可能是个不可能完成的任务。而用户的运行环境和要求却千差万别，我们不可能为每一个用户每一种运行环境设计一套一样的系统。
所以就要将一样的处理代码即业务逻辑和可能不一样的处理即数据存取逻辑分离开来，另一方面，关系型数据库中的数据基本都是以一行行的数据进行存取的，而程序运行却是一个个对象进行处理，而目前大部分数据库驱动技术（如ADO.NET、JDBC、ODBC等等）均是以行集的结果集一条条进行处理的。所以为解决这一困难，就出现 ORM 这一个对象和数据之间映射技术。
举例来说，比如要完成一个购物打折促销的程序，用 ORM 思想将如下实现（引自《深入浅出Hibernate》）：
业务逻辑如下：
public Double calcAmount(String customerid, double amount)
{
// 根据客户ID获得客户记录
Customer customer = CustomerManager.getCustomer(custmerid);
// 根据客户等级获得打折规则
Promotion promotion = PromotionManager.getPromotion(customer.getLevel());
// 累积客户总消费额，并保存累计结果
customer.setSumAmount(customer.getSumAmount().add(amount);
CustomerManager.save(customer);
// 返回打折后的金额
return amount.multiply(protomtion.getRatio());
}
这样代码就非常清晰了，而且与数据存取逻辑完全分离。设计业务逻辑代码的时候完全不需要考虑数据库JDBC的那些千篇一律的操作，而将它交给 CustomerManager 和 PromotionManager 两个类去完成。这就是一个简单的 ORM 设计，实际的 ORM 实现框架比这个要复杂的多