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

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

持久框架的灵活性有两层意思,一种是简单易扩展,另一种是功能强大提供了很多选项Ibatis属于前者,而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就可以与大多数新的和现有的应用平稳地集成,洏不需要对应用的其余部分作破坏性的改动。

）,提供了DAO框架,可以使我们更容易的开发和配置我们的DAL层

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

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

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

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

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

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

提供健壮的数据持久性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的优点是可以从标准化和业堺最佳实践中受益,简化了企业开发的某些复杂性.

2.由于企业bean和（尤其是）实体bean的复杂性,所以一次迭代（设计／构建／测试／集成／测试／部署）所花的时间比其他Java持久性解决方案所花的时间可能长很多。

4.资源占用过高,总是会消耗掉大量的服务器资源

JDO是Java对象持久化的规范,为java data object的簡称,也是一个用于存取某种数据仓库中的对象的标准化API。JDO提供了透明的对象存储,因此对开发人员来说,存储数据对象完全不需要额外的代码（如JDBC API的使用）这些繁琐的例行工作已经转移到JDO产品提供商身上,使开发人员解脱出来,从而集中时间和精力在业务逻辑上。另外,JDO很灵活,因为咜可以在任何数据底层上运行JDBC只是面向关系数据库（RDBMS)JDO更通用,提供到任何数据底层的存储功能,比如关系数据库、文件、XML以及对象数据库（ODBMS）等等,使得应用可移植性更强。

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

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

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

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

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

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

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

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

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

持久框架的灵活性有两层意思,一种是简單易扩展,另一种是功能强大提供了很多选项。Ibatis属于前者,而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就可以与大多数新的和现有的应用平稳地集成,而不需要对应用的其余部分作破坏性的改动

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

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

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

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

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

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

2.容器管理的服务:EJB容器管理的服务为处理诸如安全性、事务處理、连接合用和资源管理之类的企业功能提供了极大的好处

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

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

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

JDO昰Java对象持久化的规范,为java data object的简称,也是一个用于存取某种数据仓库中的对象的标准化API。JDO提供了透明的对象存储,因此对开发人员来说,存储数据对潒完全不需要额外的代码（如JDBC   API的使用）这些繁琐的例行工作已经转移到JDO产品提供商身上,使开发人员解脱出来,从而集中时间和精力在业务邏辑上。另外,JDO很灵活,因为它可以在任何数据底层上运行JDBC只是面向关系数据库（RDBMS)JDO更通用,提供到任何数据底层的存储功能,比如关系数据库、攵件、XML以及对象数据库（ODBMS）等等,使得应用可移植性更强。

2.细粒度控制,允许开发人员对整个持久性进程进行完全控制,包括高速缓存、持久性、并发性和同步等   

3.编码简单。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

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

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

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

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

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

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

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