持久化

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

定义

理解

二个层面(应用层系统层)

为什么要持久化

持久化的意义

持久化的相关实现(Hibernate JPA)

定义

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

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

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

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

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

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

理解

我们这样理解：

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

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

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

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

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

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

二个层面

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

为什么要持久化

持久化是一种对象服务，就是把内存中的对象保存到外存中，让以后能够取回。需要实现至少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,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层，修改量之大可见一斑。当然我们这里可以用自动生成工具生成并替换，可又有谁知道这里面的替换工作量多少?

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