标注现在已经很流行了，许多人选择它作为XML的替代来进行元数据编程。标注中不应该包含配置信息，而iBATIS通过XML来进行的工作也不光是配置。

   那么什么是配置，什么又不是呢？目前，iBATIS的XML文件包含了三方面：

• 配置信息
• 元数据信息
• 代码

   当您把环境设置改变后，您同时也需要更改配置，例如数据库连接配置、事务管理配置等等。当您将应用分发到不同的数据库，而且也使用了一些专有的SQL语句后，配置中可能还要包含SQL方言的一些配置信息。在iBATIS 3.0中我们可以将这些信息包含进去，因此，您需要针对多种方言进行编码（当然这是手工的），为它们命名，并将它们配置到适当的位置。配置信息不应该被包含在Java源文件中。

   元数据信息包括诸如结果映射、参数映射和缓存模型之类的信息。这些信息控制iBATIS如何映射您的数据以及这些映射的具体表现。

   编码包括SQL以及动态的SQL语句。

   那么标注应该承担什么样的职责呢？

   一般情况下，只有元数据信息比较适合使用标注来描述。配置应该通过属性文件或者XML文件来实现。编码也只能通过Java文件或者XML文件来实现。更进一步看，标注只能用来描述相对较简单的元数据信息。有时，标注（特别是在Java中）也会使事情变得更加复杂，使代码更加晦涩难懂。

   因为上面的原因，所以我推荐只将标注作为约定配置的替代配置。这就是说，使用这种配置方式可以达到一定的效果，但是也仅仅限于此。

   再一次强调，C#的Attribute在某些方面要强于Java的标注：

• 支持多行字符串，这使得内嵌SQL编码令人感到愉快
• 支持使用同一标注多次，而在Java中则需要通过集合标注来实现
• 支持顺序和命名参数，这使得代码变得更加简明扼要

   下面这个例子展示了如何使用Java中的标注来完成配置：

   下面这个例子要更加复杂一些，像这种使用了如此多的标注的情况就应该考虑使用XML文件来进行配置。这种情况下，我想象标注能够提供一切功能，即XML中实现的功能通过标注也能完成。然而，我们还是建议您在面对复杂的情况时使用XML来进行配置。或许某些人不是特别在意使用XML配置，所以我们为他们提供了标注配置方式。

   Clinton说：这一点是与我们以前所坚持的原则不相符合的。认识我的人都知道我基本上算是一个完美的人。但是如果我们从最佳实践的角度去考虑，我们必须在解决复杂问题的时候也使用尽量简单的解决方案。当然，那些不太喜欢约定俗成式配置的人可以忽略这种配置方式。但是我相信这是非常有用的，特别是对插入、删除和更新操作来说。使用这种配置方式，一些简单的查询也将从中受益。

   默认情况下，iBATIS 3.0将使用约定俗成式的配置方式。Java 5的方法语义中已经包含了生成SQL、进行参数和结果映射足够的信息。例如：

   这些信息对于生成以下SQL已经足够了：

   结果类型与方法的返回值类型是一致的。因为方法的返回值类型不是集合类型，所以我们知道正在处理“Select One”语义。表的名称被假定为与结果类型的名称一致。而查询参数就被假定为方法对应的参数。在使用其他的配置方式的时候，我们可以更改默认ID参数的配置。SQL语句中的各数据列假定与方法返回类型的同名属性一一对应，当然这些配置都是可以更改的。

   集合类型也是以同样的方式工作：

   这个例子将产生以下SQL语句：

   我们可以将这个例子叫做“Select Many”，因为这个方法返回了一个集合类型。我们知道Where子句为空，因为这个方法没有任何参数。

   如果我们想使用参数式查询，我们可以这样来做：

   假设只有参数的lastName，而其他引用类型都为null值，原始类型都被设置为非法无意义的值（比如-1），我们将得到以下的SQL语句：

   或者可以直接按参数来进行：

   这将生成以下的SQL语句：

   因为C#支持参数名称的反射，所以C#对这种方法提供了更好的支持。形式上也变得相对清晰，当然实质是一样的：

   更新操作也以相同的方式操作：

   也可以自动接受集合参数：

   生成器相当的灵活，而且可以为大多数删除甚至更新操作生成一条SQL语句。

   iBATIS中最古老的就是其配置方式。在项目开始的时候，XML被认为最好的配置方式。事实上，XML现在还是比较好的配置方法，因为它是进行复杂的多行SQL配置的最佳方式。因此，XML的配置方式将予以保留。但是它不再是默认的配置方式，而且也不见得是大多数应用的首选。

   iBATIS 3.0将使用多种配置方式。这就是说iBATIS将可以使用多种方式进行配置，而且这些方式可以协同工作。按照实用性排序，有以下四种方法：

• 约定俗成
• Java的标识（可以覆盖前一种配置的配置信息）
• XML（可以覆盖前两种配置的配置信息）
• Java API（可以覆盖以上配置的配置信息）

   我们应该在何处获取“Mapper”的实例呢？我们仍然需要一个核心类来完成iBATIS的配置和控制。这个核心类的名称尚在争论之中，但是我们不妨先叫它MapperFactory。

   通常情况下，MapperFactory负责构建事务和映射类的实例。而MapperFactory本身将由某个配置类来构建。

   对于这种方式是不是会使事情变得简单...或许会吧！至于事务，Clinton是这样说的：“会话的概念应该和事务的进行合并。在iBATIS中，会话和事务很多时候是一致甚至是一样的。但是它们因为一些人为的架构方面的原因而被分开了。会话或许能够完成不少任务，但是其中的80%并不适合用会话来解决。同样的，批处理操作也从事务中分离出来，因为事务在提供批处理功能是往往会导致令人生厌的try/finally的多重嵌套。因此在我们发现真实的需求之前应该尽量避免这些。”。

   iBATIS或者其他第三方库及容器都可以进行事务处理。目前，事务的处理是由SqlMapClient实例中的ThreadLocal实例来处理的。因为这种处理方法，我们配到了不少问题。不是出于技术的原因而是因为代码更加清晰，我们可以使用以下的方法：

   批处理操作可以简单地通过启动支持批处理操作的事务来进行：

   与现在的事务的API类似，我们对事务的隔离级别以及其他选项提供支持。

   如果第三方的库提供了事务处理的支持，那么受托管理的连接对象可以作为参数传入：

   总之，这样的API十分的简洁，而且易于与诸如Spring这样的第三方框架集成。MapperFactory可以被注入到需要事务管理、批处理和隔离级别的Spring的DAO对象中。为了进一步进行必要的分离，我们可以将事务管理功能从MapperFactory中分离出来，甚至于允许开发者定义自己的事务管理接口，同时将事务管理的功能绑定到类中（这样提供了更加松耦合的架构）。

   随着Java 5的推广，我们有机会来改善用户体验。其中最重要的是借助Java 5可以消除令人生惑的类型转换，可以消除SQL映射基于字符的调用方式。举例来说，现在在调用SQL映射的时候是这样的：

   问题是很明显的。第一，上面的两个例子中被映射的语句的名称都是基于字符串的，而这很容易导致错误。这种方式也不会得到IDE工具、编译器的支持和管理。

   第二个问题是存在参数和返回值类型安全问题。在第一个例子中，谁能保证参数的类型一定是Integer？而谁又能保证您得到的返回值一定是Employee类型呢？这里，编译器也不会给出任何偿错误报告和提示。而只有运行时异常会被抛出。

   最后，在集合的例子中问题也是相同的。在运行前，您可能会获得Dogs的集合，而不是Employees。

   总之，这种方式虽然比JDBC强，但是也让人倍感难受，还是存在改善的空间。

   在Java 5中我们可以充分使用范型来规范集合类型。这样，我们不需要进行特殊的配置就可以为集合类型建立一致的API。我们不需要在XML文件中声明类型，不需要通过字符名称来调用被映射的语句，相反，我们可以充分利用表达好且类型安全的接口类型。没有什么新东西需要学习，只是普通的接口就可以了。

   这就够了！iBATIS来帮我们实现这个接口。

   现在我们可以以一种更加简洁和安全的方式来调用被映射的语句了。

   在上面的调用中没有类型转换、没有字符串，而且参数和返回值的类型是、安全的。额外的代码就是针对接口使用XML或者Java的标识进行配置。最多我们只需要配置SQL语句、需要进行重载的参数或者返回值类型。

   接口描述了所需要的一切。

• 语句的名称（默认情况下与方法的名字一致）
• 参数类型（如果存在的话）
• 返回值类型（包括范型集合的元素的类型）

   而其中最有趣的就是我们可以基于方法名称这样的约定来生成SQL映射。以后关于配置的章节中将详细讨论这些细节。

   接口绑定的方法使得诸如Spring这样的框架将映射类注入其他类变得容易，同时也不需要将事务管理的过多细节公开。