iBATIS发展方向是如何呢？在过去几个月中，iBATIS获得了巨大的发展动力。作为结果，iBATIS小组发展壮大了，产品也得到了改进，我们也开始讨论支持新平台的问题了。下面我们将详细地讨论iBATIS未来的发展方向。
iBATIS发展方向1Apache软件基金会
近期，iBATIS已经成为了Apache软件基金会的一部分。我们之所以选择转向Apache，是因为我们相信他们的使命并且尊重他们的态度。Apache绝不仅仅是一堆服务器和基础设施的组合，它是一个系统，是开源软件真正的家。Apache更关注软件周边社区（即使用者社区），而不是软件背后的技术，因为如果没有社区，软件就是一个死的工程。
这对于iBATIS用户来说意味着，iBATIS并不是由某个单独的团体来指导，也不是依赖于某个单独的团体。iBATIS不属于任何个人——它属于整个社区。Apache能够始终保护iBATIS，并且确保它维持正确的方向。然而，Apache许可并没有像GPL might许可那样，限制对开源软件的使用。Apache许可并不是一个viral许可，这意味着你可以在商业环境中自由地使用这些软件，而不用担心需要遵守许多不合理的条件。
虽然Apache并不关注基础设施，但是它们确实拥有一些非常好的基础设施。目前iBATIS使用Subversion source control（SVN）进行版本控制，用Atlassian的JIRA来跟踪问题，用Atlassian的Confluence来协作撰写wiki文档，并且使用Apache的邮件列表服务器进行开发小组、用户以及一般社区之间的交流。
Apache拥有保护iBATIS所需要的一切，并且可以确保：只要仍然有人想要使用iBATIS，它就会在那儿。
iBATIS发展方向2更简单、更小、依赖性更少
和其他框架不同的是，iBATIS工程并不期望分枝出新的领域，也没有任何野心要解决所有问题。iBATIS是一个目标非常集中的工程，每一次发布新版本，我们都期望能使它更小、更简单，并且更少地依赖第三方库。
我们相信iBATIS还有许多创新的空间。iBATIS可以从很多新的技术和设计方法中获益，以便使其配置更加简练，也更容易使用。例如，C#和Java都内置了元数据（attribute，也可称为“标注（annotation）”）功能。在未来的版本中，iBATIS就有可能利用此功能来减少配置框架时所需的XML代码的数量。
在为iBATIS开发支持工具方面也还有许多事情可做。iBATIS的设计使得为其开发像IDE这样的图形化工具非常地容易。也可考虑创建支持从数据库框架（database schema）中直接生成iBATIS配置文件的工具，其实这一点上已经有相应的工具可以用了。你可以在我们的网页http://ibatis.apache.org上看到一些工具的示例。
iBATIS发展方向3更多的扩展点和插件
iBATIS已经有了许多扩展点。我们将在第12章中深入探讨有关扩展的问题。你可以实现你自己的事务处理器、数据源、缓存控制器（cache controller），以及其他。但是我们期望使得iBATIS更易于扩展。我们希望将JDBC架构的几乎每一层都设计为可扩展的，这将意味着你可以实现自己的ResultSet处理器和SQL执行引擎。这将帮助我们支持更复杂的系统，或者遗留系统以及私有系统。它也将使开发者能够更充分地利用特定数据库或应用服务器的定制特性。
iBATIS发展方向4支持更多的平台和语言
正如你在第1章和第2章中所看到的那样，我们已经在.NET和Java中讨论了iBATIS。本书的其余部分将主要关注Java版iBATIS的API，但是大部分的信息都是可以被转化成.NET平台的。另外，我们还将在附录中较详细讨论iBATIS.NET。实际上iBATIS也已经有Ruby实现了，但是Ruby是一种完全不同的语言，因此用Ruby实现的iBATIS也有很大的不同。本书中我们就不讨论其Ruby实现了。
除了Java和C#之外，iBATIS小组还在讨论用其他的语言来实现iBATIS，这些语言包括PHP 5和Python。我们相信iBATIS对于几乎任意一种无法使用或不愿使用底层数据库API和高层对象/关系映射工具的平台，都可以做出巨大的贡献。iBATIS可以帮助你找到折中的办法，并且允许你始终用一致的方式来实现所有的应用。
我们也曾经讨论过要起草一份规范，使用户可以更容易地把iBATIS移植到不同的平台上，并且确保合理的一致性。当然了，我们既希望iBATIS能够充分利用特定语言和平台的特性，也期望它们能有一定程度的相似性，以便确保它们都能被称为iBATIS，并且能够被熟悉另一种语言中的iBATIS的开发者一眼就辨认出来。
iBATIS发展方向的四方面就向你介绍到这里，希望对你了解iBATIS发展方向有所帮助。
【编辑推荐】
