iBatis简介及其不适用场合

1、iBatis与Hibernate简单对比

      Hibernate 是当前最流行的O/R mapping框架，它出身于sf.NET，现在已经成为JBoss的一部分了。

      iBatis 是另外一种优秀的O/R mapping框架，目前属于Apache的一个子项目了。 

      相对Hibernate “o/r”而言，ibatis是一种“sql mapping”的orm实现。 Hibernate对数据库结构提供了较为完整的封装，Hibernate的o/r mapping实现了pojo 和数据库表之间的映射，以及sql 的自动生成和执行。程序员往往只需定义好pojo 到数据库表的映射关系，即可通过Hibernate 提供的方法完成持久层操作。程序员甚至不需要对sql 的熟练掌握， Hibernate/ojb 会根据制定的存储逻辑，自动生成对应的sql 并调用jdbc 接口加以执行。 
      而ibatis 的着力点，则在于pojo 与sql之间的映射关系。也就是说，ibatis并不会为程序员在运行期自动生成sql 执行。具体的sql 需要程序员编写，然后通过映射配置文件，将sql所需的参数，以及返回的结果字段映射到指定pojo。 
使用ibatis 提供的orm机制，对业务逻辑实现人员而言，面对的是纯粹的Java对象。这一层与通过hibernate 实现orm 而言基本一致，而对于具体的数据操作，Hibernate会自动生成sql 语句，而ibatis 则要求开发者编写具体的sql 语句。相对Hibernate而言，ibatis 以sql开发的工作量和数据库移植性上的让步，为系统设计提供了更大的自由空间。

 
      Hibernate与ibatis的对比：

      1、ibatis非常简单易学，Hibernate相对较复杂，门槛较高。 
      2、二者都是比较优秀的开源产品 
      3、当系统属于二次开发,无法对数据库结构做到控制和修改,那ibatis的灵活性将比Hibernate更适合 
      4、系统数据处理量巨大，性能要求极为苛刻，这往往意味着我们必须通过经过高度优化的sql语句（或存储过程）才能达到系统性能设计指标，在这种情况下ibatis会有更好的可控性和表现。 
      5、ibatis需要手写sql语句，也可以生成一部分，Hibernate则基本上可以自动生成，偶尔会写一些sql。同样的需求,ibatis的工作量比Hibernate要大很多。类似的，如果涉及到数据库字段的修改，Hibernate修改的地方很少，而ibatis要把那些sql mapping的地方一一修改。 
      6、以数据库字段一一对应映射得到的po和Hibernte这种对象化映射得到的po是截然不同的，本质区别在于这种po是扁平化的，不像Hibernate映射的po是可以表达立体的对象继承，聚合等等关系的，这将会直接影响到你的整个软件系统的设计思路。 
      7、Hibernate现在已经是主流o/r mapping框架，从文档的丰富性，产品的完善性，版本的开发速度都要强于ibatis。

      以上通过对比简单介绍了iBATIS是什么，近期在读《iBATIS实战》，看到其中介绍iBATIS不适用场景一节时，觉得这部分内容很有用，可以帮助初学者加深对iBATS的理解，现将书中内容摘抄下来，组成本博客的第2节。

2、何时不该使用iBATIS

      iBATIS是一个中层的框架，它比JDBC的层次高一些，但是相对于对象/关系映射工具例如HIbernate，层次又要低一些。这使得iBATIS处于一个很独特的位置上，使它能够适用于一些较为特别的应用程序，iBatis对于多种应用程序类型（包括小的客户端应用程序和较大的、企业级Web应用程序以及任何介于这两者之间的应用程序）都是有用的。下面描述几种不适用iBATIS的情况。

2.1 当永远拥有完全控制权时

      如果能够保证拥有对应用程序设计和数据库设计的完全控制权，这在商业环境或任何一个核心工作不是软件开发的行业中是少见的。然而，如果你正在开发一个你拥有完全控制权的产品时，那么就有充分理由使用一个完全的对象/关系映射方案，如Hibernate。你可以充分利用对象/关系映射工具所能提供的设计优势并提高生产效率，可能根本没有来自企业数据库小组的干扰，也不需要与遗留系统融合。此外，数据库可能是与应用程序一同部署的，这使得它属于应用程序数据库的范畴，一个很好的使用Hibernate的示例是Atlassian的JIRA，他们提供了一个问题跟踪软件，作为一个他们可以完全控制的产品。

      然而，如果数据库有可能超出应用程序开发人员的控制，那么就必须仔细考虑使用对象/关系映射将对你的持久化策略带来的影响。一句话总结就是，如果你是全栈工程师，做web开发时后台的工作自己一个人搞定，不需要DBA插手，那么可以考虑使用像Hibernate这样更完整全面的ORM框架，否则就用iBATIS。

2.2 当应用程序需要全部使用动态SQL时

      如果应用程序的核心功能是动态生成SQL，那么 iBATIS就是错误的选择。iBATIS支持非常强大的动态SQL特性，这些特性又反过来支持高级查询能力，甚至是一些动态更新功能。然而，如果系统中的每条语句都是动态生成的，那么最好使用原始的JDBC，甚至可以创建自己的框架。

      iBATIS的强大功能之一就是它允许你拥有完全的自由，可以手工编写和直接操作SQL，当应用程序中的大部分SQL都是从某些SQL生成器类中动态 地构建时，这种优势就会丧失。

2.3 当没有使用关系数据库时

      对于关系数据库之外的其他数据库，也存在可用的JDBC驱动程序。虽然一些人在iBATIS中使用这些其他类型数据存储平台的JDBC驱动程序也获得了成功，但是对于大多数用户，我们并不推荐使用这些非关系型数据库的JDBC驱动程序。

      iBATIS并不会对你的环境做出任何假设，但是它确实期望你使用的是真正的关系数据库，即支持事务、相对典型的SQL和存储过程语义的关系数据库。即使一些非常著名的数据库也可能不支持关系数据库的某些关键特性。如MySQL的早期版本就不支持事务，因此iBATIS不能很好地处理早期版本的MySQL，幸运的是，当前MySQL已支持事务并且还有一个非常符合规范的JDBC驱动程序。

      如果你使用的不是真正的关系数据库，我们推荐你最好使用原始的JDBC，甚至更低层的文件I/O API。

2.4 当iBATIS不起作用时

      随着社区提出的需求越来越多，iBATIS也不断地实现了许多非常好的特性。然而，iBATIS有其自己的发展方向和设计目标，因此它有时候就有可能会同一些应用程序的需求发生冲突。人们在软件帮助下可以完成很多神奇的事情，但有时候 由于需求过于复杂，软件可能完全不起作用，iBATIS也是如此。虽然我们也可以在iBATIS中添加几种特性以支持这些需求，但是这么做可能会极大地提高复杂性，甚至可能会改变iBATIS框架的适用范围。因此，我们不会修改框架，为了解决以上问题，我们将提供可插拔的接口，这样就可以扩展iBATIS以满足几乎任何需求。事实上，有时候iBATIS就是不起作用，此时，最好另寻一种更好的解决方案，而不是“削足适履”地应用iBATIS。