中庸:没有最佳，只有最适! IBATIS，你合适的存活空间！

      前言：在我以前的这两篇博文：IBATIS2序：T[.WOLF]开场白和IBATIS2知识点二：放出IBATIS2.3.4.8--守护IBATIS2中，我阐述了为何开IBATIS2这个栏目，以及为何需要歇息一会儿守护着IBATIS2，并且打算进一步将有关IBATIS2 GUIDE的知识点逐步粘贴出来，为守护者提供全面的IBATIS2资源之泉。但时隔这段时间，觉得很有必要先简单的阐述下IBATIS（IBATIS2/IBATIS3）合适的存活空间，以使同仁辨别您是否值得拥有IBATIS！

      摘要：在这篇博文中，我将着重阐述持久层技术发展路线，常见持久层技术如：Apache DBUtils、Spring JdbcTemplate、IBatis、Hibernate（OJB、TopLink、EJB...）的各自特点，以及他们之间的区别与联系，从而给出IBATIS合适的存活空间！

      正文：

      ？常用持久层技术：Apache DBUtils、Spring JdbcTemplate、IBatis、Hibernate（OJB、TopLink...）;
：DBUtils：原则上不能划分到框架技术，它提供了一些Jdbc的操作封装来简化数据查询和记录读取操作。
具备一定的ResultSet封装对象能力（java反射），相对于jdbc sql代码冗余度有所降低，用起来比较方便，曾在IBatis、Spring、Hibernate等框架出现之前被广泛采用。
QueryRunner run = new QueryRunner(dataSource);
 Person p = (Person) run.query("SELECT * FROM Person WHERE name=?", "zhangsan", new BeanHandler(Person.class)); //new BeanListHandler(TestBean.class)
在DBUtils1.3版本之前，尚无法处理SELECT userid AS id FROM osc_users，因为之前的采用getColumnName()而不是getLabelName()
：Spring_JdbcTemplate：也是提供了一些Jdbc的操作封装来简化数据查询和记录读取操作，ResultSet结果集可通过RowMapper封装成需要的JavaBean，属于Spring框架一部分，Spring框架的开创性思想在于开发的“自给主义”转变为“拿来主义”（new→delegate→di，走出硬编码，容器化组织类间依赖关系，利于解耦）。
：IBatis：“半自动化”的ORM持久层框架，包括SQL Map和DAO两部分。其特点是①、开发人员自行写SQL（支持动态SQL），可细粒度优化；②走出硬编码，集中化SQL及实体类间映射；③、“半自动化”ORM映射关注点是实体类与SQL间建立映射关系；
：Hibernate：“自动化”的ORM持久层框架，对数据库结构提供了较为完整的封装，提供了从POJO（JavaBean）到数据库表的全套映射机制,只需定义好了POJO到数据库表的映射关系，即可通过 Hibernate提供的方法完成持久层操作,不需要对 SQL 的熟练掌握， Hibernate会根据制定的存储逻辑，自动生成对应的SQL并调用JDBC接口加以执行。
其特点是①自动化ORM映射关注实体类和数据库之间建立映射关系，sql对于开发人员是不可见的，无法自行SQL优化；②、用面向对象思想操作数据库；③完成实体类与库表间映射要求较高，需设良好规划且具有绝对的控制权；

     

      ？持久层技术发展主线：（思想）不断重构提供重用、简化开发、走出硬编码、追求面向对象；但值得注意的是：改变是相对的，炒作的，永远是利益驱逐的，因为我们看到从抨击硬编码中产生了配置文件模式，而如今又抨击配置文件模式带来的不便重归硬编码的路线，比如java注解、比如以硬编码的方式使用通用配置文件来减少配置文件数量以及被抨击的两者改动不一致造成的错误。因此，需要擦亮眼睛，看清本质，正如标题所指-中庸:没有最佳，只有最适，否则，就用过犹不及的滥用之嫌！

 

      ？Spring框架为IBatis&Hibernate框架带来的好处
       Spring框架可以理解为“粘合剂”，奉行“拿来主义”组装类间依赖关系，对IBatis和Hibernate进行包装，更加简化编码，提供编程式和配置式两种事务控制模式。

 

      ？常见争论的焦点（关于选型）：IBatis VS Hibernate；IBatis VS JdbcTemplate；
      Spring JdbcTemplate、IBatis、Hibernate是J2EE WEB轻量级开发最常用的持久层技术，其过渡形式可以理解为逐步走出硬编码，不断追求面向对象。她们的抽象层次越来越高，封装粒度越来越大。所以，应用她们进行开发效率越来越高。与此同时，对设计者要求也越来越高，开发者的灵活性有所限制，性能调优越来越依赖于框架自身。
     IBatis VS Hibernate：(面向数据库建模 VS 面向对象建模)老生常谈的知识点，但真正领会却不易
     Hibernate优势：①功能强大；②数据库无关性好；③O/R映射能力强；④开发速度快；劣势：①学习门槛高：设计O/R映射要求高，在性能和对象模型之间如何权衡取得平衡，以及怎样用好Hibernate方面需要经验和能力都很强才行；②无法SQL性能调优；③不适宜站在局外为系统提供统一的DAO实现。
     IBATIS优势：①学习门槛低；②数据库查询的自动对象绑定功能，且延续了很好的SQL使用经验，用于对象模型要求的项目相当完美；③可SQL性能调优；④适宜站在局外为系统提供统一的DAO实现；劣势：①因需自行写SQL，开发速度相对较慢；②数据库可移植性较差；③较强的灵活、可控性失去了类似Hibernate的面向对象思想。 
     IBatis VS JdbcTemplate：
      ①SQL编码：IBatis集中配置，JdbcTemplate硬编码；
      ②SQL参数传递：IBatis支持Java对象参数传递，适合面向对象编程，JdbcTemplate支持Object[]方式完成占位符填充；
      ③动态SQL：IBatis支持动态SQL，JdbcTemplate不得不采用if...else硬编码模式满足此功能点；
      ④对象映射：IBatis可将查询结果自动映射成JavaBean（根据配置文件，无需写任何代码），jdbcTemplate要重复手动的RowMapper或者实现MappingSqlQuery，ResultSetExtractor完成此映射功能；
      ⑤缓存Cache：IBatis内置Cache机制。
      #DBUtils&JdbcTemplate#
      同：①采用SQL硬编码；②封装jdbc sql，简化编码；③提供对ResultSet封装功能；
      异：①JdbcTemplate存在天然的Spring框架亲和性；②JdbcTemplate借助于Spring框架，简化编码、事务控制，同时，支持编程式和配置式两种开发模式。

 

      ？IBatis略胜于Hibernate的“情”：不具备整体规划设计权，对表结构及对象映射设计不可控性，如
      ①以读取数据为主的报表系统；
      ②以后台系统为主的支撑性J2EE WEB项目（以我公司为代表的一类运营支撑性的WEB系统）；
      ③以透明化的形式站在局外的角度，为后台系统实现良好的持久层；
      ④大数据量SQL性能调优。

 

      ？后台系统持久层技术要求（以我公司IDEP项目为例）：
      ①持久层透明化
      ②不懂或不甚了解JAVA WEB常用的持久层技术。后台系统以C/C++为主，开发纯 JAVA的后台系统人员大多临时抽调的C/C++人员，需要透明化持久层，以降低协作开 发难度；
      ③应用简单、灵活可控，擅长SQL方式、更多过程化思想操作DB。临时抽调的C/C++人员倾向于此方式，重要的原因是一切都在可掌控之中，所以，我们设计出的持久层必须能得到平滑过渡，且同时得到面向对象的支持；
      ④性能高效或可调优。性能高效或至少可调优不存在瓶颈；
      ⑤事务剥离。以非数据为中心，需灵活的事务服务（单点事务）控制；
      ⑥站在局外的角度设计实现统一的持久层。（对于持久层的设计人员）对表结构及对象映射设计不可控性。对于持久层的设计人员，不具备对后台系统整体的规划设计，对表结构与对象映射设计不具备可控性，站在局外的角度设计实现统一的持久层。（后台WEB支持系统受此点要求限制）。

      ？后台WEB支撑系统持久层特点：
       ①利用到后台系统库表，对这部分不具备控制权；
       ②大数据库量抽取较明显（各类报表）。

 

     ？结论：IBATIS合适的存活空间

（从“二--八”原则出发）以IBatis为核心（灵活控制、提供面向对象功能），以Spring容器为粘合剂（简化代码），以Spring JdbcTemplate为辅（性能提升-实时insert），作为后台系统（及其 WEB支撑系统&报表系统）持久层的基石。

评论

3 楼 laijavatoo 2012-05-25  

JdbcTemplate 不全面 而且 ③动态SQL：IBatis支持动态SQL，JdbcTemplate不得不采用if...else硬编码模式满足此功能点；  这一点是错误的，他有自己的支持方式。

2 楼 arcpad 2012-03-02  

任何一个能够适应大数据量并发访问的系统，都对持久层的性能瓶颈提出苛刻的要求，如果仅从代码的优雅，为了OO而面向对象，那么技术是不是也有些迷失了她本来的目的。  当项目升级修改业务，势必会修改业务代码，当然也包括配置文件。问题是，哪一个改动的多。且改动量有多大？新人接受这项工作难度有多大？以上，大部分谈到的我都赞成，但还是支持JdbcTemplate,如果在Spring JdbcTemplate之上做适合业务的持久层封装。编码量不会很大，代码可读性强，性能就不用说了。。。以上。。。

1 楼 arcpad 2012-03-02  

说的不一定对，姑且听之