java持久层框架分析

转载自http://xseven.iteye.com/blog/239341

一.  目前在java应用程序开发中,使用广泛的,开源的持久层框架是Hibernate 和 Ibatis 。 


ibatis和hibernate都是ORM解决方案,不同的是两者各有侧重。Hibernate提供了Java对象到数据库表之间的直接映射,开发者无需直接涉及数据库操作的实现细节,实现了一站式的ORM解决方案。而ibatis则采取了另一种方式,即提供Java对象到SQL（面向参数和结果集）的映射实现,实际的数据库操作需要通过手动编写SQL实现。iBatis是又一个O/R Mapping解决方案,和Hibernate相比,iBatis最大的特点就是小巧,上手很快。如果你不需要太多复杂的功能,iBatis是能满足你的要求又足够灵活的最简单的解决方案。

持久框架的灵活性有两层意思,一种是简单易扩展,另一种是功能强大提供了很多选项。Ibatis属于前者,而Hibernate属于后者。 


Hibernate 

简介： 

它是一个开放源代码的对象关系映射框架,它对JDBC进行了非常轻量级的对象封装,使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库。 

Hibernate可以应用在任何使用JDBC的场合,既可以在Java的客户端程序实用,也可以在Servlet/JSP的Web应用中使用,Hibernate可以在应用EJB的J2EE架构中取代CMP,完成数据持久化的重任。

Hibernate的目标是成为Java中管理持续性数据问题的一种完整的解决方案。它协调应用与关系数据库的交互,让开发者解放出来专注于手中的业务问题。 

Hibernate是一个和JDBC密切关联的框架,所以Hibernate的兼容性和JDBC驱动,和数据库都有一定的关系,但是和使用它的Java程序,和App Server没有任何关系,也不存在兼容性问题。

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和Apache OJB等“一站式”ORM解决方案而言,IBatis是一种“半自动化”的ORM实现。 

这个框架将让你能够更好的在JAVA应用中设计和实现实体层。这个框架有两个主要的组成部分,一个是SQL Maps,另一个是Data Access Objects。另外还包括一些可能很有用的工具。

使用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.实用：提供了数据映射功能,提供了对底层数据访问的封装（例如ado.net）,提供了DAO框架,可以使我们更容易的开发和配置我们的DAL层。 

4.灵活：通过sql基本上可以实现我们不使用数据访问框架可以实现的所有功能,或许更多。 

5.功能完整：提供了连接管理,缓存支持,线程支持,（分布式）事物管理,通过配置作关系对象映射等数据访问层需要解决的问题。提供了DAO支持,增强系统的可维护性： 

6.SQL集中管理,因为我们不能保证程序员写的复杂SQL没问题。 

缺点： 
1.iBATIS的缺点就是框架还是比较简陋,功能尚有缺失,虽然简化了数据绑定代码,但是整个底层数据库查询实际还是要自己写的,工作量也比较大,而且不太容易适应快速数据库修改。

2.它是一个半ORM,工具支持较少：需要手写sql,并且未发现可以自动生成业务层类和配置文件的工具,这注定了Ibatis不能从本质上提升开发效率,我们需要自己写sql,写实体类,写配置文件。但这也是它优越的地方,它没有为我们做的他多,所以我们就有更多的施展空间。而且它非常适合那些并不能完全控制数据库的系统和需要利用数据库本身提供的高级特性的统计查询系统的开发。

个人意见： 强烈推荐 


二. 持久层的框架中非开源项目则以EJB为主要代表： 

EJB的entiy Bean ： 

简介：  
提供健壮的数据持久性。bean容器处理大部分的数据完整性、资源管理和并发性功能,从而使开发人员关注业务逻辑和数据处理,而不是这些低级细节。使用bean管理的持久性（Bean ManagedPersistence,BMP）实体bean时,开发人员编写持久性代码而容器确定何时执行该代码。使用容器管理的持久性（Container Managed Persistence,CMP）实体bean时,容器生成持久性代码并管理持久性逻辑。 


优点：  

1.标准化:EJB规范定义一组与供应商无关的接口,J2EE供应商可以实现这些接口来支持实体bean。这种标准化允许采用最佳实践的开发并缩短雇用新开发人员时的适应期。

2.容器管理的服务:EJB容器管理的服务为处理诸如安全性、事务处理、连接合用和资源管理之类的企业功能提供了极大的好处。 
  
3.透明持久性:CMP时容器能自动管理持久性语义。虽然使用BMP实体bean时,开发人员必须编写持久性逻辑,而容器则确定何时调用由开发人员定义的方法。同时使用CMP和BMP实体bean时,容器决定何时持续保持bean的状态以及如何确保与底层数据存储的数据完整性和并发性。 

4.事务支持:开发人员对CMP事务（隔离级别、事务需求和方法的包含／排除）有粗粒度的控制权,对BMP事务有细粒度的控制权,这些控制都是通过在bean代码中以程序方式处理事务语义实现的。在这两种情况下,容器管理事务并确定是否应该提交给定的事务。 

5.基于组件的设计:实体bean被设计成自包含组件,这些组件配置有部署描述符,无需更改任何代码就可以将它们部署到任何J2EE应用程序服务器。 

总体来说,entiy bean的优点是可以从标准化和业界最佳实践中受益,简化了企业开发的某些复杂性. 

缺点： 
  
1.设计复杂。  
  
2.由于企业bean和（尤其是）实体bean的复杂性,所以一次迭代（设计／构建／测试／集成／测试／部署）所花的时间比其他Java持久性解决方案所花的时间可能长很多。 
  
3.响应时间不理想  
  
4.资源占用过高,总是会消耗掉大量的服务器资源。 

个人意见：不推荐 



JDO： 

简介： 

JDO是Java对象持久化的规范,为java data object的简称,也是一个用于存取某种数据仓库中的对象的标准化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也有这样的趋势,就像App Server的差别一样,一个在Weblogic上开发好的EJB,移植到Websphere,你一定需要重新进行配置。 

个人意见：不推荐 

三. 自行开发持久层框架评估： 

优点： 

1.对框架的熟悉程度比使用已有产品相对较好,能够深度了解底层机制,能够最大限度的使用框架的功能, 使用起来灵活自如, 功能扩展也比较方便。 

2.提高开发人员的持久层设计经验。 

可能存在的问题： 

1.如果缺乏对JDBC的了解和数据持久层开发的经验,可能自己开发的数据持久层会慢慢的不满足业务需求,也就是功能可能不够强大,比如在数据缓存、连接池管理、多数据库支持等等方面

2.如果对设计模式,持久层设计思想没有足够的了解和经验,框架可能缺乏可扩展性,结构不够灵活。 

3.可能会耗费较多的人力和时间。 

个人意见： 

不管JDO也好,Hibernate也好,ibatis也好,软件的使用和配置方法可以各异,但本质上都是ORM,都是对JDBC的对象持久层封装,所以万变不离其宗,我觉得只有在用过目前已有的一些开源持久层框架,深入理解它们的持久层设计思想,有了一定的技术积累后,才能设计出适合于我们的项目的持久层。