iBATIS是一个中层的框架。它比JDBC更高层一些，但是相对于对象/关系映射工具，又要更底层一些。这使得iBATIS处于一个很独特的位置上，使它能够适用于一些较为特别的应用。在本书前面的部分，我们讨论了为什么iBATIS对于多种应用类型都是有用的，包括小的桌面应用，和较大的、企业级的Web应用——以及任何介于这两者之间的应用类型。那么，iBATIS不适用的场合是什么呢？下面几节就将详细描述不适合使用iBATIS的各种情况，并且给出有关替代方案的建议。
iBATIS不适合使用之1当你能永远拥有完全控制权时
如果你能够保证拥有对应用设计和数据库设计的完全控制权，那你一定是一个非常幸运的人。这在商业环境或者任何一个核心工作不是软件开发的行业中都是非常少见的。然而，如果你在一个软件公司工作，并且在开发一个你拥有完全设计控制权的且由你发售的产品时，那么你可能恰好处于这种情况。
当你具有完全控制权时，就有充分理由使用一个完全的对象/关系映射方案，如Hibernate。你可以充分利用对象/关系映射工具所能提供的设计优势并提高生产率。可能根本没有来自企业数据库组的干扰，也不需要与遗留系统整合。此外，数据库可能是与应用一同部署的，这使得它属于应用数据库的范畴（参见第1章）。使用Hibernate的应用的一个很好的例子就是，Atlassian的JIRA。它们提供了一个问题跟踪软件，作为一个他们可以完全控制的发布产品。
然而，还需要考虑应用未来的发展。如果数据库有可能超出应用开发者的控制，那么你就必须仔细考虑一下使用对象/关系映射将对你的持续化策略带来怎样的影响。
iBATIS不适合使用之2当你的应用需要完全动态的SQL时
如果你的应用的核心功能是动态生成SQL，那么iBATIS就是错误的选择。iBATIS支持非常强大的动态SQL特性，这些特性又反过来支持高级查询能力，甚至一些动态更新功能。然而，如果你的系统中每个语句都是动态地生成的，那么你***使用原始的JDBC，甚至可以创建你自己的框架。
iBATIS的强大功能之一就是它允许你拥有完全的自由，可以手工编写和直接操作SQL。当应用中大部分的SQL都是从某些SQL生成类动态地生成时，这种优势就会很快丧失。
iBATIS不适合使用之3当你并没有使用关系数据库时
对于关系数据库之外的其他数据库，也存在可用的JDBC驱动。对于平板文件，微软Excel电子数据表，XML，以及其他类型的数据存储平台，都有相应的JDBC驱动。虽然一些人在iBATIS中使用这些驱动也获得了成功，但是对于大多数用户我们并不推荐使用这些驱动。
iBATIS并不会对你的环境做出任何假设。但是它确实期望你使用的是真正的关系数据库，即支持事务、相对典型的SQL、和存储过程这些语义的关系数据库。即使一些非常著名的数据库也可能不支持关系数据库的某些重要特性。如MySQL的早期版本就不支持事务，因此iBATIS不能很好地处理MySQL。幸运的是，当前的MySQL已支持事务并且还有一个非常符合规范的JDBC驱动。
如果你使用的不是真正的关系数据库，我们推荐你***使用原始的JDBC，甚至更底层的文件I/O API。
iBATIS不适合使用之4当iBATIS不起作用时
随着社区提出的需求越来越多，iBATIS也不断地实现了许多非常好的特性。然而，iBATIS是有其自己的发展方向和设计目标的，这样一来它有时候就有可能会同一些应用的需求发生冲突。人们在软件帮助下可以完成很多神奇的事情，但是有时候由于需求过于复杂，软件可能会完全不起作用，iBATIS也是如此。虽然我们也可以在iBATIS中添加特性以支持这些复杂的需求，但是这么做可能会极大地提高复杂性，甚至可能会改变iBATIS框架的适用范围。因此，我们不会修改框架。为了解决以上问题，我们将提供可扩展的接口，这样你就可以扩展iBATIS以满足几乎任何需求。事实上，有时候iBATIS就是不起作用。此时，***另寻一个更好的解决方案，而不是“霸王硬上弓”地将iBATIS（或者其他任何框架）用在不合适的地方。
iBATIS不适合使用的时期就向你介绍到这里，那么通过介绍你是不是对iBATIS不适合使用的时期有点自己的认识呢？
【编辑推荐】
