最近突然出现了对象/关系 映射构架（比如JDO和Hibernate） 和SQL映射构架（比如iBATIS）这些不是凭空出现的。相反，他们是在JAVA 联盟在JDBC屡造挫折之后才出现的。为了了解新构架出现的原因，这里咱们回顾一下直接使用JDBC会出现的问题。在许多程序中直接使用JDBC不是一个好的选择，主要有以下三个原因：。 开发和维护SQL非常的困难而且耗费时间――一些开发者发现要写庞大而且复杂的SQL语句非常的困难。反映数据库变化的SQL语句会变得非常耗时。你必须小心的考虑牺牲可维护性是否值得。。 用SQL会使移植性变的很差――因为需要数据库的特殊SQL语句。如果一个程序和多个数据库有关系，那么你就要写多个版本的SQL语句，这使得可维护性变变成噩梦。。 直接写JDBC代码要会非常耗时，而且容易出错。你必须写很多的样板代码去获得连接，创建和初始化适当的声明，还要用精确的声明去清理连接。而且你还要写代码去将JAVA 对象映射到SQL声明。由于要无奈的去写，JDBC代码很容易出错。
如果你的程序必须直接运行SQL语句的话，那前面两个问题是无法避免的。有时候为了获得好的性能，必须要全力的写SQL语句，包括供应商提供的那些特殊东西。由于许多业务上的原因，持久层可能会产生混乱的SQL语句，为了防止这种情况，DBA可能要求你的程序来完全控制SQL语句的执行。通常，团队买进的关系型数据库过于庞大，以至于应用程序工作时会出现一些和数据库有关的琐碎事务。根据“iBATIS in Action”的作者说这里会有一种情况出现：“数据库或者SQL语句本身存在的时间比程序代码存在的时间还要长，或者同一段SQL语句或数据库有多个程序的版本。有些情况下，程序已经用另外一种语言重写了，但是SQL语句和数据库却没有太大的改变。” 如果直接使用SQL弄的你筋疲力尽，那么很幸运，这里有一种直接执行SQL语句的构架，它可比用JDBC要容易多了。当然了，这就是iBATIS.
使用iBATIS
我开发过的所有企业JAVA应用程序，都是直接执行SQL语句的。早期的程序是执行特定的SQL语句的，后来是用持久层构架再用少量的SQL语句构成的。一开始我直接用JDBC来执行SQL语句，但是后来，我经常写一些小的构架去完成JDBC中那些比较无聊的部分。我也用过一段Spring的JDBC类，这些类除去了JDBC中的许多样板代码。但是无论是我自己写的构架还是使用Spring的类，在Java类映射到SQL语句的时候都会存在问题，这就是我为什么那么高兴的加入iTATIS 那边的原因了。
文章来源于领测软件测试网 https://www.ltesting.net/
