java持久化技术Word下载.docx
- 文档编号:17842381
- 上传时间:2022-12-11
- 格式:DOCX
- 页数:12
- 大小:28.80KB
java持久化技术Word下载.docx
《java持久化技术Word下载.docx》由会员分享,可在线阅读,更多相关《java持久化技术Word下载.docx(12页珍藏版)》请在冰豆网上搜索。
Hibernate是一种非强迫性的解决方案。
开发者在写业务逻辑与持续性类时,不会被要求遵循许多Hibernate特定的规则和设计模式。
这样,Hibernate就可以与大多数新的和现有的应用平稳地集成,而不需要对应用的其余部分作破坏性的改动。
优点:
1.Hibernate功能强大,数据库无关性好,O/R映射能力强,如果精通Hibernate,而且对Hibernate进行了适当的封装,那么项目整个持久层代码会相当简单,需要写的代码很少,开发速度很快。
2.hibernate体现了OO编程的思想,许多OO的特性都可以用上,比如:
继承,多态。
而且有利于代码的重用。
比如你有一个DAO,其中有一个save(Object)方法,那么,对于任何需要保存的对象,把它当作参数传给这个方法就可以了。
3.方便系统的移植,对于不同的数据库系统,对于已经编写好的系统,一般情况下,只需要修改hibernate配置文件的dialect,那么它就会生成对应的数据库的sql语句。
4.有着正确的数据模型。
以POJO为基础的模型是个正确的方向;
可配置性(例如对象之间的关系)是个很好的基础;
HSQL正是O/R映射语言应该有的;
有着完整的API;
采用简明的Session类作为控制流的清洗器,因为它沿用了Connection的模型
5.开源和免费的License,可以在需要的時候研究源代码,改写源代码,进行功能的定制。
具有可扩展性,API开放,当本身功能不够用的时候,可以自己编码进行扩展
6.hibernate已经成为了事实上的标准,目前使用的人多,所以技术支持也多,有什么问题也很容易在网络上寻求解决方案。
缺点:
1.学习门槛不低,要精通门槛更高,在设计O/R映射,在性能和对象模型之间如何权衡取得平衡,以及怎样用好Hibernate方面需要丰富的经验。
2.Hibernate不适合数据库模式不规范,约束不完整,需要大量复杂查询的系统。
个人意见:
推荐使用
IBatis:
相对于Hibernate和ApacheOJB等“一站式”ORM解决方案而言,IBatis是一种“半自动化”的ORM实现。
这个框架将让你能够更好的在JAVA应用中设计和实现实体层。
这个框架有两个主要的组成部分,一个是SQLMaps,另一个是DataAccessObjects。
另外还包括一些可能很有用的工具。
使用ibatis提供的ORM机制,对业务逻辑实现人员而言,面对的是纯粹的Java对象,这一层与通过Hibernate实现ORM而言基本一致,而对于具体的数据操作,Hibernate会自动生成SQL语句,而ibatis则要求开发者编写具体的SQL语句。
相对Hibernate等“全自动”ORM机制而言,ibatis以SQL开发的工作量和数据库移植性上的让步,为系统设计提供了更大的自由空间。
作为“全自动”ORM实现的一种有益补充,ibatis的出现显得别具意义。
1.易于学习,易于使用,通过文档和源代码,可以比较完全的掌握它的设计思路和实现。
提供了数据库查询的自动对象绑定功能,而且延续了很好的SQL使用经验,对于没有那么高的对象模型要求的项目来说,相当完美。
(简单:
我们都喜欢简单,简单意味着学习成本低,使用中出错的可能性低。
同时,简单的东西一般来说功能不够强大。
反过来,复杂的东西学习成本高,用起来不方便,并且团队没有很强的技术实力,一般不要使用。
)
2.最大的优点是可以有效的控制sql发送的数目,提高数据层的执行效率!
它需要程序员自己去写sql语句,不想hibernate那样是完全面向对象的,自动化的,ibatis是半自动化的,通过表和对象的映射以及手工书写的sql语句,能够实现比hibernate等更高的查询效率。
3.实用:
提供了数据映射功能,提供了对底层数据访问的封装(例如),提供了DAO框架,可以使我们更容易的开发和配置我们的DAL层。
4.灵活:
通过sql基本上可以实现我们不使用数据访问框架可以实现的所有功能,或许更多。
5.功能完整:
提供了连接管理,缓存支持,线程支持,(分布式)事物管理,通过配置作关系对象映射等数据访问层需要解决的问题。
提供了DAO支持,增强系统的可维护性:
6.SQL集中管理,因为我们不能保证程序员写的复杂SQL没问题。
1.iBATIS的缺点就是框架还是比较简陋,功能尚有缺失,虽然简化了数据绑定代码,但是整个底层数据库查询实际还是要自己写的,工作量也比较大,而且不太容易适应快速数据库修改。
2.它是一个半ORM,工具支持较少:
需要手写sql,并且未发现可以自动生成业务层类和配置文件的工具,这注定了Ibatis不能从本质上提升开发效率,我们需要自己写sql,写实体类,写配置文件。
但这也是它优越的地方,它没有为我们做的他多,所以我们就有更多的施展空间。
而且它非常适合那些并不能完全控制数据库的系统和需要利用数据库本身提供的高级特性的统计查询系统的开发。
强烈推荐
二.持久层的框架中非开源项目则以EJB为主要代表:
EJB的entiyBean:
提供健壮的数据持久性。
bean容器处理大部分的数据完整性、资源管理和并发性功能,从而使开发人员关注业务逻辑和数据处理,而不是这些低级细节。
使用bean管理的持久性(BeanManagedPersistence,BMP)实体bean时,开发人员编写持久性代码而容器确定何时执行该代码。
使用容器管理的持久性(ContainerManagedPersistence,CMP)实体bean时,容器生成持久性代码并管理持久性逻辑。
1.标准化:
EJB规范定义一组与供应商无关的接口,J2EE供应商可以实现这些接口来支持实体bean。
这种标准化允许采用最佳实践的开发并缩短雇用新开发人员时的适应期。
2.容器管理的服务:
EJB容器管理的服务为处理诸如安全性、事务处理、连接合用和资源管理之类的企业功能提供了极大的好处。
3.透明持久性:
CMP时容器能自动管理持久性语义。
虽然使用BMP实体bean时,开发人员必须编写持久性逻辑,而容器则确定何时调用由开发人员定义的方法。
同时使用CMP和BMP实体bean时,容器决定何时持续保持bean的状态以及如何确保与底层数据存储的数据完整性和并发性。
4.事务支持:
开发人员对CMP事务(隔离级别、事务需求和方法的包含/排除)有粗粒度的控制权,对BMP事务有细粒度的控制权,这些控制都是通过在bean代码中以程序方式处理事务语义实现的。
在这两种情况下,容器管理事务并确定是否应该提交给定的事务。
5.基于组件的设计:
实体bean被设计成自包含组件,这些组件配置有部署描述符,无需更改任何代码就可以将它们部署到任何J2EE应用程序服务器。
总体来说,entiybean的优点是可以从标准化和业界最佳实践中受益,简化了企业开发的某些复杂性.
1.设计复杂。
2.由于企业bean和(尤其是)实体bean的复杂性,所以一次迭代(设计/构建/测试/集成/测试/部署)所花的时间比其他Java持久性解决方案所花的时间可能长很多。
3.响应时间不理想
4.资源占用过高,总是会消耗掉大量的服务器资源。
不推荐
JDO:
JDO是Java对象持久化的规范,为javadataobject的简称,也是一个用于存取某种数据仓库中的对象的标准化API。
JDO提供了透明的对象存储,因此对开发人员来说,存储数据对象完全不需要额外的代码(如JDBC
API的使用)。
这些繁琐的例行工作已经转移到JDO产品提供商身上,使开发人员解脱出来,从而集中时间和精力在业务逻辑上。
另外,JDO很灵活,因为它可以在任何数据底层上运行。
JDBC只是面向关系数据库(RDBMS)JDO更通用,提供到任何数据底层的存储功能,比如关系数据库、文件、XML以及对象数据库(ODBMS)等等,使得应用可移植性更强。
1.设计简单。
2.细粒度控制,允许开发人员对整个持久性进程进行完全控制,包括高速缓存、持久性、并发性和同步等。
3.编码简单。
JDO
体系结构向开发人员隐藏了低级别的持久性细节。
4.JDO并不仅仅使Java对象持久;
它还透明地处理整个相关对象图的持久性。
因此,当实例被持久存储时,它所维护的对其它对象实例的任何内部引用也都被持久存储(除非它们已被声明为瞬态)。
JDO还存储类型层次结构的完整信息,并能根据类型(父类和接口)实现请求,而不是只了解持久实例的特定局部类型。
1.JDO没有一个好的开源免费实现,好的产品都是商业产品,并且在国内没有销售和技术支持。
这就造成了JDO只有学习之用,不能把它用在实际项目中,否则的话,你把软件卖给客户的时候,还要告诉他,你还要另外去买一个国外的软件产品,并且在国内没有技术支持,出了持久层的问题,我们也解决不了,请你自己打国际长途去解决问题,你认为客户能答应吗?
2.JDO不是一个轻量级封装,它试图建立一个完整的持久层框架,但是还很不完善,造成了JDO感觉比较笨重,很多操作方式令人觉得烦琐和古怪。
这加重了程序员学习和编程的负担,而且封装的太多会造成一个严重的问题就是一旦出现报错信息,调试起来非常困难,你很难准确的定位错误究竟出在哪里,封装的越轻,问题越容易定位,越容易解决,封装的越重,问题越复杂,越找不到原因,CMP就是一个很好的例子,出了错误,调试起来非常困难和麻烦。
3.JDO的标准很不完善,存在重大缺陷。
最主要的问题体现在PO不能脱离PM(相当于Hibernate的Session)而存在,这是个非常严重的问题,会造成编程的时候进行大量VO的拷贝操作,烦琐极了;
另外一个重大缺陷是静态的POJO的Enhancer,不能运行期动态Enhance,无法进行增量编译和调试,编程和调试起来非常烦琐,每次都要手共运行一个工具对POJO进行Enhance;
此外还有一些缺陷,例如JDOQL不完善,映射关系的表达不够强大等等。
4.JDO产品的分裂。
这个问题也比较严重,由于JDO1.0标准的缺陷,而各个JDO厂商为了能够在竞争中脱颖而出,那么除了在易操作性和性能上的提高之外,想要吸引客户,就必须有自己的产品特色。
那么1.0标准的缺陷正好给了他们发挥的舞台,每个厂商都会有自己独到的解决方案来解决标准的缺陷,然而这却造成了JDO产品事实上的分裂。
这种分裂严重到什么程度?
我可以简单举个例子:
你写好的POJO,用一种JDO的Enhancer进行Enhance过以后得到的PO,在另一个JDO产品上跑不起来。
这很像当年Unix的分裂,结果就是二进制代码级的不兼容,而只能在C源代码级兼容。
现在的JDO也有这样的趋势,就像AppServer的差别一样,一个在Weblogic上开发好的EJB,移植到Websphere,你一定需要重新进行配置。
三.自行开发持久层框架评估:
1.对框架的熟悉程度比使用已有产品相对较好,能够深度了解底层机制,能够最大限度的使用框架的功能,使用起来灵活自如,功能扩展也比较方便。
2.提高开发人员的持久层设计经验。
可能存在的问题:
1.如果缺乏对JDBC的了解和数据持久层开发的经验,可能自己开发的数据持久层会慢慢的不满足业务需求,也就是功能可能不够强大,比如在数据缓存、连接池管理、多数据库支持等等方面
2.如果对设计模式,持久层设计思想没有足够的了解和经验,框架可能缺乏可扩展性,结构不够灵活。
3.可能会耗费较多的人力和时间。
不管JDO也好,Hibernate也好,ibatis也好,软件的使用和配置方法可以各异,但本质上都是ORM,都是对JDBC的对象持久层封装,所以万变不离其宗,我觉得只有在用过目前已有的一些开源持久层框架,深入理解它们的持久层设计思想,有了一定的技术积累后,才能设计出适合于我们的项目的持久层。
Java持久层选择Hiberante和iBATIS比较
Hibernate是进行持久层开发的重要框架,它提供了与数据库无关的API接口,可以让开发者不必关心数据库的差异,重点关注业务层的开发。
iBATIS是又一个O/RMapping解决方案,和Hibernate相比,iBATIS最大的特点就是小巧、容易上手,并且它是基于SQL的解决方案,其执行效率等价于直接使用JDBC。
8.1.1Hibernate开发流程
Hibernate是Java应用和关系数据库之间的桥梁,它负责Java对象和关系数据之间的映射。
Hibernate内部封装了通过JDBC访问数据库的操作,向上层应用提供了面向对象的数据访问API。
在Java应用中使用Hibernate包含以下步骤:
(1)创建Hibernate的配置文件:
该文件负责初始化Hibernate配置,包括数据库配置和映射文件配置;
(2)创建Hibernate映射文件:
每一个数据表对应一个映射文件,该文件描述了数据库中表的信息,也描述了对应的持久化类的信息;
(3)创建持久化类:
每一个类对应一个数据库表,通过映射文件进行关联;
以上三步是开发Hibernate要实现的关键内容。
接下来就要面向Web应用层进行编码,通常会分为DAO层和Service层:
(1)编写DAO层:
通过HibernateAPI编写访问数据库的代码;
(2)编写Service层:
编写业务层实现,调用DAO层类代码;
图3-2显示了调用的过程及Hibernate在应用中所处的位置。
图3-2Hibernate开发流程图
8.1.2iBATIS开发步骤
iBATIS是Java应用和关系数据库之间的桥梁,它负责Java对象和关系数据之间的映射。
iBATIS内部封装了通过JDBC访问数据库的操作,向上层应用提供了面向对象的数据访问API。
在Java应用中使用iBATIS包含以下步骤:
(1)创建iBATIS的配置文件:
该文件负责初始化iBATIS配置,包括数据库配置和映射文件配置;
(2)创建iBATIS映射文件:
以上三步是开发iBATIS要实现的关键内容。
通过iBATISAPI编写访问数据库的代码;
图8-1显示了调用的过程及iBATIS在应用中所处的位置。
图8-1iBATIS开发流程图
8.1.3选择Hibernate还是iBATIS
从以上iBATIS的开发过程可以看出,它与Hibernate的开发过程是一一对应的,都是由映射文件和持久化类作为底层数据库的沟通接口,上层调用iBATIS或Hibernate的API来编写DAO和Service层。
但是在实际的应用中,它们则拥有各自的特点,这也决定了它们适用的场合。
(1)Hibernate的特点:
Hibernate功能强大,数据库无关性好,O/R映射能力强,如果对Hibernate相当精通,而且对Hibernate进行了适当的封装,那么整个持久层代码会相当简单,需要写的代码很少,开发速度很快。
Hibernate对数据库结构提供了较为完整的封装,Hibernate的O/RMapping实现了POJO和数据库表之间的映射,以及SQL的自动生成和执行。
程序员往往只需定义好了POJO到数据库表的映射关系,即可通过Hibernate提供的方法完成持久层操作。
程序员甚至不需要对SQL的熟练掌握,Hibernate/OJB会根据制定的存储逻辑,自动生成对应的SQL并调用JDBC接口加以执行。
Hibernate的缺点就是学习成本高,要精通需要更多的时间,而且如何设计O/R映射,在性能和对象模型之间如何权衡取得平衡,以及怎样用好Hibernate方面需要更多的经验和能力,但是Hibernate现在已经是主流O/RMapping框架,从文档的丰富性,产品的完善性,版本的开发速度都要强于iBATIS。
(2)iBATIS的特点:
iBATIS入门简单,即学即用,提供了数据库查询的自动对象绑定功能,而且延续了很好的SQL使用经验,对于没有那么高的对象模型要求的项目来说,相当完美。
当系统数据处理量巨大,性能要求极为苛刻,这往往意味着我们必须通过经过高度优化的SQL语句(或存储过程)才能达到系统性能设计指标。
在这种情况下iBATIS会有更好的可控性和表现。
在实际的开发来说,二者有以下区别:
●iBATIS需要手写SQL语句,也可以使用工具自动生成,Hibernate则基本上可以自动生成,编码时需要编写HQL;
●iBATIS可以进行细粒度的优化,原因是iBATIS是基于SQL的;
●在不考虑Cache的情况下,iBATIS应该会比Hibernate快很多。
总而言之,Hibernate叫iBATIS复杂,学习成本高,iBATIS简单容易上手,是基于原生SQL的框架。
可以说,Hibernate功能强大而复杂,iBATIS简单小巧。
由此你也不难判断在什么情况下选择什么框架了。
Java持久化深度理解
java中常用域对象持久化技术的比较
目前java中共有5种常用的实现持久化的模式:
1jdbc直接访问数据库
2主动域对象模式
3cmp模式
4orm模式
5jdo模式
1、jdbc实现数据库访问的方式是在业务方法中直接嵌入sql语句,sql语句是面向关系的,依赖于关系模型。
所以jdbc方式的优点是简单直接,特别是对于小型应用十分方便。
但是jdbc这种实现方式也给应用程序带来以下缺点:
(1)、实现业务逻辑的代码和数据库访问代码掺杂在一起,使程序结构不清晰,可读性差。
(2)、在程序代码中嵌入面向关系的sql语句,使开发人员不能完全运用面向对象的思维来编写程序。
(3)、业务逻辑和关系数据模型绑定,如果关系数据发生变化,必须手工修改代码中所有相关的sql语句,这曾经了维护软件的难度。
(4)、如果程序代码中sql语句包含语法错误,在编译时不能检查这种错误,只有在运行时才能发现这种错误,这增加了调试程序的难度。
正是由于上述的缺点,为了使业务逻辑和数据访问细节分离,出现了下面的几种模式。
2、主动域对象模式
主动域对象是实体域对象的一种形式,它在实现中封装了关系数据模型和数据访问的细节。
在j2ee架构中,ejb组件分为会话ejb和实体ejb。
会话ejb通常实现业务逻辑,而实体ejb表示业务实体。
实体ejb又分为两种:
由ejb本身管理持久化,即bmp(bean-managedpersistence);
由ejb容器管理持久化,即cmp(container-managedpersistence)。
bmp就是主动域对象模式的一个例子,bmp表示由实体ejb自身管理数据访问细节。
主动域对象模式有以下优点:
(1)、在实体域对象中封装自身的数据访问细节,过程域对象完全负责业务逻辑,使程序结构更加清晰。
(2)、如果关系数据模式发生变化,只需要修改主动域对象的代码,不需要修改过程域对象的业务方法。
主动域对象模式有以下缺点:
(1)、在实体域对象的实现中仍然包含sql语句。
(2)、每个实体域对象都负责自身的数据访问实现。
把这一职责分散在多个对象中,这会导致实体域对象重复实现一些共同的数据访问操作,从而造成重复编码。
主动域对象本身位于业务逻辑层,因此采用主动域对象模式时,整个应用仍然是三层应用结构,并没有从业务逻辑层分离出独立的持久化层。
3.cmp模式
在j2ee架构中,cmp(container-managedpersistence)表示由ejb容器来管理实体ejb的持久化,ejb容器封装了对象-关系的映射及数据访问细节。
cmp和orm的相似之处在于,两者都提供对象-关系映射服务,都把对象持久化的任务从业务逻辑中分离出来。
区别在于cmp负责持久化实体ejb组件,而orm负责持久化pojo,它是普通的基于javabean形式的实体域对象。
cmp模式的优点在于:
(1)、他是基于ejb技术,是sunj2ee体系的核心部分,获得了业界的普遍支持,包括各大厂商和开源组织等。
如果选择它作企业级开发,技术支持会非常完备。
(2)、功能日趋完善,包括了完善的事务支持,ejbql查询语言,透明的分布式访问等等
cmp模式的缺点在于:
(1)、开发人员开发的实体必须遵守复杂的j2ee规范,而多少orm中间件没有类似要
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- java 持久 技术