作为软件开发人员，我已经在许多不同的环境中工作过。即使是在同一家公司中，软件开发的方式也往往是迥然不同的。开发人员每天都要面对各种各样的挑战、面对不同的人和工具，考虑到这一点，你就会迅速了解他们的世界是多么的变化多端。我永远也不知道下一个项目又会有怎样惊人的挑战，因此我总是在工具箱中保留着各种各样的工具。在很长一段时间内，iBATIS只不过是这个工具箱中的一种普通工具。当我不得不手写JDBC代码时，它可以帮我节省很多时间。

那么，iBATIS是如何从我的工具箱中的普通工具转变为一个为成千上万的人使用的Apache项目的呢？其实原本我从没打算过使iBATIS成为一个完全成熟的开源项目。所以尽管它的源代码就在那儿，但我从没想过把它推向市场，也从没主动地和任何人分享过它，直到JPetStore。

故事发生在2002年7月1日，我针对网上流传的关于Pet Store的讨论发了一个帖子。当时位于Redmond的一家大型软件公司宣称其C#语言和.NET平台的生产率要比Java高出好几个数量级。我在技术上持中立态度，虽然我承认C#和.NET的确相当之好，但是我仍然不能接受上述这种论断。因此连续几个星期，我用晚上的时间编写了JPetStore，以之反驳他们的论断。JPetStore发布后，在Java社区引起了广泛的讨论。其中讨论得最为热烈的话题就是JPetStore没有使用Enterprise JavaBeans（EJB）的持久化层，而是用了一个称为iBATIS的小型框架。

经常有人问我：“为什么不用其他开源工具？”实际上，当时根本没有像iBATIS那样的工具。代码生成器倒是有很多，有开发时（development-time）代码生成工具，有构建时（build-time）代码生成工具，在此我就不对它们过多赘述了。我只强调一点：任何能够被生成的代码在经过适当的泛化（generalized）后都应该可以被抽取出来，成为一个框架或者某个框架的一部分。而这正是iBATIS的本质：一个用于加快JDBC编程的经过泛化的框架。

另一个被经常问到的问题就是，“为什么不用对象/关系映射（O/RM）工具？”只要环境合适，你当然可以使用O/RM工具。例如，当你可以完全控制数据库和对象模型时，O/RM工具就非常有效：你可以毫不费力地得到理想的对象关系映射；反之，如果你无法同时控制它们，那么当两者之间存在不匹配时（这几乎是肯定的），使用O/RM就会成为一场噩梦，因为它们必须匹配。但是，要为我经常处理的数据库类型建立与对象模型之间的映射几乎是不可想象的。当然，使用一个好的O/RM工具，如Hibernate或者TopLink，也许可以做到。但问题是：真的应该去建立这种映射吗？

曾经有人给我讲过一个故事，故事中那个拿着锤子的人总是把所有东西都看作是钉子——哈哈，是否觉得似曾相识！回到我们的话题，O/RM工具实际上是一种框架。而框架总是构建于约束和假设之上。这些约束和假设在某些环境中是理想的，但并不适用于所有的环境——不要因为拿着锤子就把所有的东西都看作钉子J。作为软件开发人员，我们的工作就是用那些理想的解决方案去匹配我们遇到的实际问题，并非只能使用那些我们知道的方案或者最流行的方案，或者网上最热门的方案，而应该使用那些能够最好地解决我们所面对的问题的方案。总之，不同的环境需要不同的工具——iBATIS就是这众多不同工具中的一种。

到目前为止，iBATIS已经在3种语言中得到了实现：Java、C#和Ruby。并且有一个由十几个开发人员组成的小组在专门维护它，同时它还拥有一个由成千上万的开发人员组成的社区。你可以在图书和文章中，甚至在Web上的博客中学习它。虽然iBATIS算不上（也似乎根本不可能成为）持久化框架的翘楚，但它仍然是一个巨大的成功。另外，回答关于iBATIS的各种问题这个任务现在已经由社区全面接管了，如果你们不满意以上问题的答案或者仍然有什么其他问题，欢迎到社区提问。

有一个能够完全“独立自主、自力更生”的社区是一个开源项目取得成功的真正标志。如果你早就读到过这句话，我猜你一定是该社区的一份子。因此让我们一同庆祝iBATIS这个小小框架的巨大成功吧。

Clinton Begin

iBATIS持久化框架的创始人

JPetStore应用程序的缔造者

iBATIS之父的大作——《iBATIS 实战》