Hibernate与IBatis的优缺点及可行性分析

1.优点

　　简单：

　　易于学习，易于使用，通过文档和源代码，可以比较完全的掌握它的设计思路和实现。

　　实用：

　　提供了数据映射功能，提供了对底层数据访问的封装（例如ado.net），提供了dao框架，可以使我们更容易的开发和配置我们的dal层。

　　灵活：

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

　　功能完整：

　　提供了连接管理，缓存支持，线程支持，（分布式）事物管理，通过配置作关系对象映射等数据访问层需要解决的问题。提供了dao支持，并在dao框架中封装了ado.net，Hibernate和datamapper。

　　增强系统的可维护性：

　　通过提供dal层，将业务逻辑和数据访问逻辑分离，使系统的设计更清晰，更易维护，更易单元测试。sql和代码的分离，提高了可维护性。

2.缺点

　　滞后性：

　　还没有明确对.net2.0的支持。最新版本在2.0下编译可以，但有些单元测试不能通过。

　　不成熟，工程实践较少：

　　ibatisnet在实际项目中的使用较少。 只是理论上可行.

　　半orm，工具支持较少：

　　需要我们自己写sql，并且.net下还未发现可以自动生成业务层类和配置文件的工具，这点和Hibernate不一样，Hibernate会为我们的数据库直接产生sql，并有一些辅助工具。因此使用ibatis比Hibernate要多做一些工作。

3.可行性

　　没有最好的框架，只有最适合的框架。 存在的便是合理的，它存在就说明有它存在的道理。但它未必为我们存在。所以选择一个框架最主要的是看它对你有没有意义，意义有多大，是不是比其他框架带给 你的好处要多。没有绝对的优点也没有绝对的缺点，重要的是看在什么情况下讨论。

　　上面说了部分的ibatis的优点和部分缺点。这些优点从理论上证明ibatis对任何数据持久层都合适，但未必是最好的选择。下面对上面的优缺点分别从两方面讨论。

简单：

　　我们都喜欢简单，简单意味着学习成本低，使用中出错的可能性低。同时，简单的东西一般来说功能不够强大。反过来，复杂的东西学习成本高，用起来不方便，并且团队没有很强的技术实力，一般不要使用。

　　实用：

　　解决了项目中需要解决的问题，这是任何实际工程中采用的框架和工具都应具有的性质，否则就不要拿到实际项目中来。

　　灵活：

　　灵活有两层意思，一种是简单易扩展，另一种是功能强大提供了很多选项。ibatis属于前者，Hibernate属于后者。两者各有优缺点。

　　功能完整：

　　ibatis的功能完整也是相对的，比我们自己开发的框架应该完整，但对比其他框架肯定也有一些解决不了的问题。

　　增强系统的可维护性：

　　利用ibatis可以做到sql和代码分离，可以设计出一个清晰的数据访问层（dal）。但项目架构是否科学合理，是否以维护，关键不在ibatis，因 为它只是一个数据层框架。但是我们也不得不清楚，要想发挥ibatis的优势，我们需要做一些额外工作，比如最好设计dao接口，需要将业务层实体和对实 体的访问放在不同的工程中，同时需要维护xml配置文件。

　　滞后性：

　　ibatis组现在还没有提到要支持.net2.0，很多人在.net2.0下使用ibatis都出现了问题。所以如果要使用.net2.0开发，ibatis不是一个好选择，还需要等待。

　　不成熟：

　　开源的东西很难说成熟，但一般比我们自己写的框架要成熟。由于我们可以拿到他的源代码，所以关键在于我们能否驾驭它。

　　半orm，工具支持少：

　　这注定了ibatis不能从本质上提升开发效率，我们需要自己写sql，写实体类，写配置文件。但这也是它优越的地方，它没有为我们做的他多，所以我们就 有更多的施展空间。而且它非常适合那些并不能完全控制数据库的系统和需要利用数据库本身提供的高级特性的统计查询系统的开发。

使用ibatis需要自己写sql，由于我们的sql不可能完全符合sql标准，比起Hibernate产生的sql来，可移植性差。不过由于我们更改 数据库的可能性较小，对我们来说sql符合标准以便可以在迁移到不同服务器时代价最小并不是十分必要的。另一方面，Hibernate虽然可以屏蔽很多 数据库间的不同，但是却很难利用某些数据库的高级特性，比如oracle的分析统计函数。

　　Hibernate不适合数据库模式不规范，约束不完整，需要大量复杂查询的系统，同时Hibernate的学习成本较高，完全掌握Hibernate也较困难，风险较大。

　　自己写框架未必比ibatis的好，稳定，强大和可扩展。而且自己开发框架也需要较大的工作量。

　　如果使用dotnet并且要选一个数据层框架，而系统中有相当一部分较复杂的sql，或数据库设计不合理，脏数据多，对性能和资源要求严格，ibatis 是一个比较不错的选择。他的那些缺点并不是致命的，而且也是有一些解决方案的。尤其是，当选用了ibatis的dataaccess作为dao框架时，我 们可以同时使用Hibernate，ado.net和datamapper（ibatisnet的核心组件），那样将会使风险降到最低，并且整个系统的 框架比较合理。

　　另外，利用ibatis可以统一编码风格，节约开发成本，大家不会再把精力浪费到分页 连接池 主键生成等地方了,可以集中精力进行业务组件的编写。

　　综上: 很多时候我们要在是自己开发框架和选用第三方框架和选用什么样的框架问题上进行综合考虑。考虑的标准当然是项目的当前情况和我们希望达到目的的一个平衡。

　　ibatis只是封装了数据访问层，替我们做了部分的对象关系映射。但我们的代价是必须要写xml配置文件，相对于Hibernate我们还要写很多 sql。Hibernate通过工具直接从数据库模式生成实体类和基本的配置文件，而且大部分情况下不需要我们写sql，会较大的提升开发效率。但这些也 有很多的局限性，尤其是对环境的要求较高（数据库设计，对象设计，团队的协作等）。

个人感觉ibatis对项目比较有意义的地方在于它小巧灵活，可扩展，封装了数据访问层（事务，缓存，异常，日志），并提供了dao框架支持。

　　利用ibatis我们可以做到代码和sql的分离，只要sql能够解决的问题，ibatis就能帮我们较容易的解决，同时也使我们的项目对某一框架的依赖 性变小（因为ibatis是非侵入性的）。这将极大的降低项目风险，减少解决复杂问题的时间，使项目的维护变得简单。

　　ibatis对于应用的修改，调试，扩充和维护将会变得容易自然。修改时，我们主要修改的是代表模型的实体对象，xml配置文件中的sql，和/或配置文 件的resultmap（很多时候是不需要的）。同时，sql和代码分离，我们不用在代码的stringbuffer的append方法之间寻找需要修改 的sql。配置文件中的sql便利了我们的调试和对sql的评审及以后的sql重用。

　　利用一些框架在前期一般会拖慢开发效率。因为我们需要付出学习成本，很多时候，使用框架需要写很多配置文件，在使用不熟时开发速度较慢；同时利用框架往往 使系统代码量增大，比如model1和model2模型，开发效率应该还是model1快，四层的架构肯定比两层的代码量大。 但对于中后期开发和维护将会极大的提高效率。

　　利用一些较完全的开发框架和代码生成工具，在前期会较大的提高开发效率，但在后期常常会拖慢进度，并有可能成为以后维护的梦魇。比如torque生成实体类和其对应的sql，虽大幅提高了效率，但修改负担较大。

　　比较理想的开发方式是使用简单框架结合简单的代码生成工具。框架提供系统的基础服务，并规范开发。框架一方面提供了开发中某一方面的开发基础支持，比如数 据访问层，事务，日志，公用类，异常等。另一方面，也为开发定义了模式，定义了系统的基本轮廓。同时，通过简单的代码生成工具生成部分低级的代码。比如通 过工具从数据库模式生成实体类。这些类生成后我们可以自由修改。

 

　　Hibernate是十分强大，比较完善的orm框架，不过这是它的优点也是它的缺点。 J2EE系统是否采用Hibernate3，是一个需要认真评估的问题。

　　要想Hibernate工作的好，数据库的设计必须好。同时对于复杂的数据操作同时需要使用sql，Hibernate3对于直接使用sql的支持比Hibernate2要自然，这一点是可以接受的。

　　Hibernate比较复杂，功能强大而灵活，要用好Hibernate确实不是很简单，当然spring框架提供了对Hibernate的封装，使Hibernate的使用变得简单了点。

　　可以说ibatis在任何系统里都适用，但未必是最好选择。不过ibatis提供的思路是我们应该仔细考虑的。

 

 

 

评论

13 楼 fight_bird 2010-06-26  

油炸大龙虾 写道

fight_bird 写道

老生常谈的问题，几个观点：
1、只从数据库中查询当前页数据是分页的基本要求。

2、若提供精确的总记录数，则大数据量下分页的性能瓶颈是sql count(*)函数执行耗时。

3、某些分页需求是不合理的，如几万条数据分页，阅读者能做什么？

4、分页、排序、列定制、前后台协作、UI风格、数据所见所得的导出等诸多特性综合一起的分页组件不是一个容易的事情。

count(*)可以到索引表里查。
83W数据count(*)我机器要20sec+;
查索引表闪电

索引表的限制很多，索引表方式不具有普遍的适用性，解决count(*)性能问题技术上有好几个方法都能达到效果，但正如我上面强调的，当count(*)都已经出现性能问题时，这种数据量下的分页浏览的需求本身就问题。

12 楼 llfzy 2010-06-24  

我现在一般用iBATIS！

11 楼 油炸大龙虾 2010-04-21  

fight_bird 写道

老生常谈的问题，几个观点：
1、只从数据库中查询当前页数据是分页的基本要求。

2、若提供精确的总记录数，则大数据量下分页的性能瓶颈是sql count(*)函数执行耗时。

3、某些分页需求是不合理的，如几万条数据分页，阅读者能做什么？

4、分页、排序、列定制、前后台协作、UI风格、数据所见所得的导出等诸多特性综合一起的分页组件不是一个容易的事情。

count(*)可以到索引表里查。
83W数据count(*)我机器要20sec+;
查索引表闪电

10 楼 mathgl 2010-04-16  

ibatis in action 那本书 曾经提到过 两者的应用场景

如果是要维护旧的系统，那么ibatis的封装效果会更好些。原有的系统不一定按照oo来设计。

如果是新系统，developers拥有控制权，那么可以采用hibernate。

9 楼 fengmy123 2010-04-08  

需要经常维护修改的代码，还是别太复杂的好。。

8 楼 超级潜水艇 2010-03-15  

ibator的一个问题又回归了---那就是sql类似的代码又写回到了java代码中去了，而xml配置所留下的是一些高度动态的sql组装片段，也就是在一般的单表查询时不用在xml中拼装任何sql代码

7 楼 kevindude 2010-03-15  

nothinkinperson 写道

kevindude 写道

引用

这注定了ibatis不能从本质上提升开发效率，我们需要自己写sql，写实体类，写配置文件

难道你不知道有个叫ibator的东西吗？

难道你不知道ibator不支持ibatis3吗

难道你不知道ibator 1.22 snapshot已经开始支持ibatis3了吗？

6 楼 nothinkinperson 2010-03-13  

kevindude 写道

引用

这注定了ibatis不能从本质上提升开发效率，我们需要自己写sql，写实体类，写配置文件

难道你不知道有个叫ibator的东西吗？

难道你不知道ibator不支持ibatis3吗

5 楼 kevindude 2010-03-12  

引用

这注定了ibatis不能从本质上提升开发效率，我们需要自己写sql，写实体类，写配置文件

难道你不知道有个叫ibator的东西吗？

4 楼 ckn126 2010-03-09  

解释的非常独特，收益非浅。特别是说关于框架的使用“有最好的框架，只有最适合的框架。 存在的便是合理的，它存在就说明有它存在的道理。但它未必为我们存在。所以选择一个框架最主要的是看它对你有没有意义，意义有多大，是不是比其他框架带给 你的好处要多。没有绝对的优点也没有绝对的缺点，重要的是看在什么情况下讨论。”这几句非常好。框架没有最完美，只有最合适该项目的框架

3 楼 llfzy 2010-01-27  

这里面的代码都是公司项目里面的的，也只能截取出部分代码！

2 楼 llfzy 2010-01-27  

fight_bird 写道

老生常谈的问题，几个观点：
1、只从数据库中查询当前页数据是分页的基本要求。

2、若提供精确的总记录数，则大数据量下分页的性能瓶颈是sql count(*)函数执行耗时。

3、某些分页需求是不合理的，如几万条数据分页，阅读者能做什么？

4、分页、排序、列定制、前后台协作、UI风格、数据所见所得的导出等诸多特性综合一起的分页组件不是一个容易的事情。

呵呵，可能跟各个开发者的用途不一样吧！我主要是做Lucene全文检索的，每次建立索引都是上百万条，总不可能把全部数据都加载在内存中撒，sql count(*)函数应该没的把所有数据加载出来耗时撒！至于你提到的前台什么分页定制，我程序中已经实现了。都是公用的统一分页方式。这里尽对一次性加载超级大量数据库，我这测试是通过了的！比以前的方式节约内存很多！
  

1 楼 fight_bird 2010-01-27  

老生常谈的问题，几个观点：
1、只从数据库中查询当前页数据是分页的基本要求。

2、若提供精确的总记录数，则大数据量下分页的性能瓶颈是sql count(*)函数执行耗时。

3、某些分页需求是不合理的，如几万条数据分页，阅读者能做什么？

4、分页、排序、列定制、前后台协作、UI风格、数据所见所得的导出等诸多特性综合一起的分页组件不是一个容易的事情。