持久 化（Persistence），即把数据（如内存中的对象）保存到可永久保存的存储设备中（如磁盘）。持久化的主要应用是将内存中的对象存储在关系型的数据库中，当然也可以存储在磁盘文件中、XML数据文件中等等。

持久化是将程序数据在持久状态和瞬时状态间转换的机制。

JDBC就是一种持久化机制。文件IO也是一种持久化机制。

将鲜肉冷藏，吃的时候再解冻的方法也是。

将水果做成罐头的方法也是。

将人的脏器迅速冷冻，运输，然后解冻给人移植的技术也是。 ^[1]

我们这样理解：

在一定周期内保持不变就是持久化,持久化是针对时间来说的.

数据库中的数据就是持久化了的数据,只要你不去删除或修改.

比如在IE浏览器中一次Session会话中Session对象 变量也是不变的,是Session容器中持久化

对象持久化的方式有很多种,根据周期不同有,page,Session,Application,

对象序列化机制对于需要将对象的状态保存到文件中，而后能够通过读入对象状态来重新构造对象，恢复程序状态,

对象序列化的过程是 对象持久化的方法之一,把对象保存到文件中.

简单的理解持久化可以在二个层面：应用层和系统层、

如果关闭(shutdown)你的应用然后重新启动则先前的数据依然存在。

如果关闭(shutdown)你的系统（电脑）然后重新启动则先前的数据依然存在。

持久化是一种对象服务，就是把内存中的对象保存到外存中，让以后能够取回。需要实现至少3个接口：

void Save(object o) 把一个对象保存到外存中

Object Load(object oid) 通过对象标识从外存中取回对象

bool Exists(object oid) 检查外存中是否存在某个对象

为什么需要持久化服务呢？那是由于内存本身的缺陷引起的：

内存掉电后数据会丢失，但有一些对象是无论如何都不能丢失的，比如银行账号，遗憾的是，人们还无法保证内存永不掉电。

内存过于昂贵，与硬盘、磁带、光盘等外存相比，内存的价格要高2~3个数量级，而且维持成本也高，至少需要一直供电吧。所以即使对象不需要永久保存，也会因为内存的容量限制不能一直呆在内存中，需要持久化来缓存到外存。

既然持久化服务在看得到的未来还有市场，我们就来看看如何构建一个好的持久化框架，框架是否真的好在于如何在扩展性、缩放性、重用性上取得良好的平衡：

扩展性，如果一个持久性框架不能支持用户定义的类型，显然不是一个好的框架。

缩放性，保存和取回对象都需要耗费cpu、 带宽、时间资源，哪一个消耗太多都不能接受。

重用性是我们建立 框架的初衷，就是通过框架能够减少一些编码和测试的工作量。

这几个需求往往是互相冲突的，所以关键是平衡。

我们先跳开一下，看看另一个类似的有用概念：序列化，序列化也是一种对象服务，就是把内存中的对象序列化成流、或者把流反序列化成对象。需要实现2个接口：

void  Serialize( Stream  stream,object o) 把对象序列化到流中

object Deserialize(Stream stream) 把流反序列化成对象

序列化和持久化很相似，有些人甚至混为一谈，其实还是有区别的，序列化是为了解决对象的传输问题，传输可以在 线程之间、进程之间、内存外存之间、 主机之间进行。我之所以在这里提到序列化，是因为我们可以利用序列化来辅助持久化，可以说凡是可以持久化的对象都可以序列化，因为序列化相对容易一些（也不是很容易），所以主流的软件基础设施，比如.net和java，已经把序列化的框架完成了。

持久化方案可以分为关系数据库方案、文件方案、对象数据库方案、 xml数据库方案，现今主流的持久化方案是关系数据库方案，关系数据库方案不仅解决了并发的问题，更重要的是，关系数据库还提供了持久化服务之外的价值：统计分析功能。刚才我说到，凡是可以序列化的对象都可以持久化，极端的说，我们可以只建立一个表Object(OID,Bytes)，但基本上没有人这么做，因为一旦这样，我们就失去了关系数据库额外的统计分析功能。

关系数据库和面向对象之间有一条鸿沟，因为2中模式不匹配，所以就存在一个OR映射问题。

当持久化兴起的时候，逐渐形成了实体层这个概念了。hibernate ^[2] ,jdo,以及博客园的nbear都可谓是大名鼎鼎！有的公司不使用这种ORM 框架,他们使用一些自动生成工具生成实体(例如用Codesmith生成)，并生成和该表对应的业务逻辑，于是乎感觉我们的程序好像一下子全都写好了，下一步就轻松了，我们只要扩展业务即可了!莫非这样真是那么方便了？在维护上真的是最便捷吗？ 其它的 持久层解决方案不敢说，但至少我觉得像orm的鼻祖hibernate那种开发机制,在维护还是相当之麻烦呀！一个实体还得对应一个xml文件（虽说这些都可以自动生成）,但是你深入项目的时候去想想，我们的业务真能一切都可以定下来吗？人的思想总是在变的，客户的需求就更难以琢磨了！哪天我们要给数据库加个字段，你想想你必须要走几步改动？首先我们必须重新生成xml和实体，然后我们必须还得在业务逻辑中增加代码，还得在视图层加一个界面(如加一个input输入框等)！讲实话，加一个字段对这种 orm框架的改动还是最少的，哪天假如说我们修改了哪个字段的名称、修改了字段类型，你想想，天呐！很难想像，和这个字段关联的程序都得改动!如果名称改了，ok，你可以全部替换它的原先名称，改成你新的名称。那类型改了呢？没办法只能手工一个个改掉所有的赋值的类型吧？视图层、控制层中的验证（js验证,业务验证）、逻辑层、实体层，xml配置等等都必须动。搞啥个hsq，这和sql不差不多了吗（虽然说hsq，抽象了 数据库模型）？不过我想没有程序员不懂 sql的吧？况且hsq对复杂的语句还是会力不从心的吧！

运用ORM框架势必会运用大量的反射，代价是牺牲性能。当然现今的各种ORM框架都在尝试使用各种方法来减轻这块（LazyLoad，Cache），效果还是很显著的。可是我们牺牲了这么大的性能，而且我是觉得在维护上ORM还是最便捷。

真不知道为啥像hibernate这样的框架还有一个xml配置文件？如果我真ORM的话，我不能把这些数据关系缓存起来，动态取关系不就行了吗？这样我不更灵活了吗？

当然使用ORM也有它的活的活之处，在维护上那种自动生成的方式( petshop模式)比使用ORM 框架维护量上更大一些，那种构架如果是每个数据操作对应一个 存储过程的改动会更会让人晕头转向的。其构架大致如以下描述：

主要由BLL,MODEL,DAL三层构架方式实现，BLL存放的是相关业务，MODEL是相关的数据库表格实体，DAL业务的SQL语句（或 存储过程参数）.为了松散耦合，在BLL层和DAL层中间加入了工厂层(Factory)，其作用是方便DAL层的载体变动(如把Sqlserver改成Mysql),在DAL层有一个setObject数据库字段到实体属性设置,便于数据库表格映射成实体。

程序编写的最大问题就是 耦合高，怎么降耦也是开发的一个重中之重。以上述的程序构架来看，如果我改动了数据库中的其中一个表格的某个字段，程序改动的至少就有三层。如果再按照自动生成方式那种看，DAL中的update,insert,select, setObject都需要改动，如果存在 存储过程的话，像get,getAll,update,insert都必须改动，想象一下这里改动地方有几处了？而且还需改动Model层，修改量之大可见一斑。当然我们这里可以用自动生成工具生成并替换，可又有谁知道这里面的替换工作量多少?

总之，提倡"高内聚，低耦合"是构架永恒的话题，寻找便捷亦是构架的终级目标。

hibernate为应用程序提供了高效的O/R关系映射和查询服务，为 面向对象的领域模型到传统的 关系型数据库的映射，提供了一个使用方便的框架。

JPA（Java Persistense API）是EJB3.0的一部分，为其提供了一套O/R关系映射的API，但不仅限于EJB中使用，它也可以在web应用或者应用程序 客户端中被使用，甚至在Java 桌面程序中被使用。