原理：
1.实现JavaBean的属性到数据库表的字段的映射：
--通过配置文件将JavaBean的属性与数据库表的字段的关联起来
2.映射关系:
一对多，多对一等
持久层（Persistence Layer）：专注于实现数据持久化应用领域的某个特定系统的一个逻辑层面，将数据使用者和数据实体相关联。
数据持久化：数据持久化就是将内存中的数据模型转换为存储模型，以及将存储模型转换为内存中数据模型的统称。数据模型可以是任何数据或对象模型，存储模型可以使关系模型、XML、二进制等
O/R M:
目的：利用面向对象的多台处理业务逻辑，而不是繁多的 if else
特征：
--关联以及与此相关的Lazy Load, O/R M是如何管理类之间的关联.当然这不仅于O/R M有关与设计者的设计水平也有很大关系.
--O/R M对继承关系的处理.
--O/R M对事务的支持.
--O/R M对查询的支持
内涵：
应用面向对象的思想，而不是纯粹的关注如何保存数据，将CRUD这些操作放入对象
对象关系映射：
目的：面向对象与关系数据库不匹配的问题
特征：描述对象和数据库之间的元数据
本质：将数据从一种形式转换为另一种形式
内涵：
业务实体:
--在内存中以对象的形式表现
--在数据库中以关系数据的形式表现
现象：对象具有继承、多态等特性，关系数据库是无法表达这些关系的
在关系型数据库和业务实体对象之间作一个映射，这样，我们在具体的操作业务对象的时候，就不需要再去和复杂的SQL语句打交道，只要像平时操作对象一样操作它就可以了。
透明性：在计算机技术中，一种本来是存在的事物或属性，但从某个角度看似乎不存在，称为透明性现象
例：qq之间的对话表面上看在qq与qq之间进行，实际上是qq与传输层进行
O/R映射层是持久层的一个特例，它的数据模型是对象模型（Object），存储模型是关系模型（Relational），cmp和Hibernate是对象模型到关系模型之间转换的两种不同实现。由于对象模型和关系模型应用广泛，所以很多人错误的认为数据持久层就是对象模型到关系型数据库的转换，其实持久化的范围更广一些。
案例1：
持久层(Persistence Logic):
EJB：
Entity Bean：包含持久层逻辑
特征：
·BMP实现，还要实现相关的persistence logic
·CMP有容器的支持,使得 persistence的实现不再需要用户
太费神
·查询数据库相关对象需要Entity中的home接口
自身的行为放到了XXXEntityManager
缺点：
失去了面向对象的特征，变成了结构化的模型，类成了一个数据和函数的包装体
dao模式：某种程度上解决了持久层逻辑的分离
特征：将dao从Entity Bean中分离了出来，没有破坏Bean的内部实现没有完全解决业务逻辑和持久层逻辑分离问题
猜想：对象自身的属性的变化(业务逻辑影响)，要体现到数据库中，怎样能避免在业务逻辑中操作持久层逻辑时能将对象的状态变化，体现到数据库中？
--在完成一个业务逻辑后自动的检测到对象状态所发生的变化.随后在事务提交时,将发生的变化保存到数据库中
案例2：
Entity：实体(类似于j2ee中的Entity Bean)通常指一个承载数据的对象, 但是注意它也是可以有行为的! 只不过它的行为一般只操作自身的数据.
Domain Object：对象最重要的特性在于它拥有行为. 仅仅拥有数据,你可以称它为对象, 但是它却失去它最重要的灵魂.
需要和别的对象(不是Value Object)打交道的对象,我就不再称其为实体. 领域模型就是指由这些具有业务逻辑的对象构成的模型.
POEAA：
Table Gateway：以表为单位的实体集合,基本没有行为,只有CRUD操作.
Row Gateway：以行为单位的实体,基本没有行为,只有CRUD操作.
Active Record:以行为单位的实体,拥有一些基本的操作自身数据的行为(如上例中的GetName),同时包含有CRUD操作
Active Record中是充满了SQL语句的(不像orm的SQL透明), 所以有人想起来利用O/R m来实现"Active Record", 虽然在他们眼里看起来很方便, 其实根本就是返祖.
Data Mapper:这才是真正的O/R m,Hibernate等等工具的目标.
案例3：
hibernate：
重要特征：缓存机制
基本特征：
--Hibernate会监视对象的变化.所有的更新只要在事务提交的时候就会保存到数据库中(透明性)
--将持久层逻辑从业务逻辑中分离
实现Transparent persistence我认为是Hibernate最为成功的地方之一, 也是高层的O/R M应该起到的作用.动态生成SQL语句只是实现这一目的的手段之一, 不要把它作为O/R M的实质.
业务逻辑(Business Logic)：
1.从Persistence的角度Business Logic的分类:
涉及属性改动,需要反映到Persistence Layer的Business Logic (需要Facade的事务包装)
仅仅读取相关属性, 没有需要反映到持久层的Business Logic
2.从Domain Object角度对Business Logic的分类:
由一个根(Root)Domain Object通过直接的属性关联实现的Business Logic(dependent object)
由多个独立的Domain Object通过Facade联系起来一起完成的Business Logic(session bean)