定义:
持久化(Persistence),即把数据(如内存中的对象)保存到可永久保存的存储设备中(如磁盘)。持久化的主要应用是将内存中的数据存储在关系型 的数据库中,当然也可以存储在磁盘文件中、XML数据文件中等等。持久化是将程序数据在持久状态和瞬时状态间转换的机制。JDBC就是一种持久化机制。文 件IO也是一种持久化机制。将鲜肉冷藏,吃的时候再解冻的方法也是。 将水果做成罐头的方法也是。将人的脏器迅速冷冻,运输,然后解冻给人移植的技术也是。
理解:
我们可以这样理解: 在一定周期内保持不变就是持久化,持久化是针对时间来说的. 数据库中的数据就是持久化了的数据,只要你不去删除或修改. Session会话中Session对象变量也是不变的,是Session容器中持久化 对象持久化的方式有很多种,根据周期不同有,page,Session,Application, 对象序列化机制对于需要将对象的状态保存到文件中,而后能够通过读入对象状态来重新构造对象,恢复程序状态, 对象序列化的过程是对象持久化的方法之一,把对象保存到文件中.
二个层面:
简单的理解持久化可以在二个层面:应用层和系统层、
应用层
如果关闭(shutdown)你的应用然后重新启动则先前的数据依然存在。
系统层
如果关闭(shutdown)你的系统(电脑)然后重新启动则先前的数据依然存在。
为什么要持久化:
在很多地方看到持久化,从java中的serialize,传说中的轻量级持久化,到 j2ee中的 持久层 , 都提到了.我理解了一天的结果是,只看到了它带来的好处,但一直没完全明白为什么非要用它,直到看到这篇文章,解惑.在这里,谢谢市长 (转) 持久化是一种对象服务,就是把内存中的对象保存到外存中,让以后能够取回。需要实现至少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层,修改量之大可见一斑。当然我们这里可以用自动生成工具生成并替换,可又有谁知道这里面的替换工作量多少? 总之,提倡"高内聚,低耦合"是构架永恒的话题,寻找便捷亦是构架的终级目标。