目录
学习笔记一 - 概念与入门
学习笔记二 - 基础配置
学习笔记三 - 高级技巧与进阶
学习笔记四 - 技巧与实践
本笔记均学习自 《iBATIS实战》
介绍
1、iBATIS的理念
章节内容：
- iBATIS的历史
- 理解iBATIS
- 数据库的类型
iBATIS的建立基于这样一个思想：关系型数据库和SQL仍然很有价值
很多应用程序的源代码随着时间的流逝过时了，但是它的数据库甚至SQL本身仍然很有价值。
出于这样的原因，iBATIS并不试图去隐藏或者避免使用SQL。相反，正是iBATIS这个持久层框架广泛使用了SQL，它使得SQL更容易使用、更容易集成到现代的面向对象软件中。
1.1 一个结合了所有优秀思想的混合型解决方案
iBATIS是一个混合型的持久层解决方案，它汲取了大量用于执行SQL的优秀方法。
1.1.1 iBATIS的根源
iBATIS从目前最流行的关系数据库访问方法中吸收了大量的优秀特征和思想，并找出其中的协同增效作用。在接下来的这几节将讨论这些不同的数据库访问方法，以及iBATIS从每种方法中汲取的优秀思想。
SQL
iBATIS的核心是SQL。SQL是一种简单的、非过程化的语言，用于操纵数据库，它包含两种语言：
数据库定义语言(Data Definition Language,DDL),其中包含CREATE、DROP以及ALTER。这些语句用于定义数据库数据及其设计。iBATIS不直接支持DDL，虽然可以实现控制，但是并不推荐。DDL通常应该由某个数据库管理小组拥有并控制，应用程序的开发人员无权操控它。
数据操纵语句(Data Manipulation Language,DML),DML包括SELECT、INSERT、UPDATE以及DELETE这样的用于直接操纵数据库的语句。
老式存储过程
许多遗留系统使用的都是“两层（two-tier）”的设计。“两层”设计包括一个富客户端界面来直接调用数据库的存储过程。“两层应用程序”的最大问题在于性能和扩展性以及部署时的会出现的大量问题。
现代存储过程
现代存储过程通常被当做来自中层（middle tier）的远程过程调用（remote procedure call,RPC）并且许多性能方面的约束也可以通过建立间接池和数据库资源管理等方式解决了。存储过程的优势在于性能，他可以更快的完成数据库中的数据操作。把业务放入存储过程是一个糟糕的设计，存储难以编写、测试、部署以及应对出现的变化（变更数据库是需要受到最严格的变更控制保护）。
数据库的开放商为了解决这个问题嵌入了其他语言（JAVA,C#），来编写更加强大的存储过程，而内联SQL就是这个解决方案的产物（并且引入了等量的完全不同的新问题）。
内联SQL
解决存储过程固有限制的方法之一就是将SQL嵌入更加通用的语言中。与存储过程将业务逻辑从应用程序移入数据库相反，内联SQL将SQL从数据库移入了应用程序。 以下就是JAVA重使用SQLJ的一个示例：
String name;
Date hiredate;
#sql{
SELECT emp_name,hire_date
INTO : name,:hiredate
FROM employee
WHERE emp_num = 28
}本地变量可以直接传递给SQL作为参数，SQL的执行结果可以直接复制给类似的变量。某种意义上，SQL称为了该语言的一个特性。
但是，由于SQL的版本问题，预编译器问题（内联SQL需要一个预编译器将它翻译为当前语言的的相应代码）。解决内联SQL的这些问题的方案之一就是将SQL从语言级移除，代之以应用程序中的某种数据结构(如字符串)来表现，即动态SQL（dynmaic SQL）。
动态SQL
动态SQL被表现为一种字符串类型的数据，可以像现代语言所有其他类型的字符数据一样操纵它。因动态SQL被表示为一种字符串类型，所以他不能像内联SQL一样直接与语言进行交互（也避开了预编译器问题）。因此动态SQL的实现需要一组强壮的API，用来设置SQL参数，获取结果数据。
动态SQL的优点在于其灵活性。SQL可以在运行时基于不同的参数或动态的应用程序来构建，动态SQL是目前现代变成语言访问关系数据库的方法中最流行的。大多数这样的现代变成语言都包括用于进行数据库访问的标准API，如JAVA的JDBC,C#的ADO.NET。
动态SQL的缺点在于代码不优雅，复杂，冗长，并且重复。导致SQL的可读性很差。
O/RM
O/RM（对象/关系映射）是用来被设计为简化对象持久化工作的，它通过将SQL完全从开发人员的职责中排除来达到这个目的。在O/RM中，SQL是生成的，他基于应用程序中的类与关系数据库的表之间的映射。
现代的O/RM工具不仅能简单地产生几条SQL，还能够提供一套完整的持久化架构。功能包括事物管理功能，高速缓冲策略（避免不必要的数据库访问），数据延迟加载技术。
O/RM工具是基于一些假设和规则的。最普遍的假设就是数据库被恰当的规范化了。但是大量的数据库并没有很好的规范，使得映射的过程很麻烦，使得O/RM往往只是一个数据库全部功能中的一个子集。
1.1.2 iBATIS的优势
正如前文多次强调的，iBATIS是一个混合型解决方案，它汲取了前面这些解决方案里最有价值的思想并且融会贯通。
| 方案 | 相同的有点 | 解决的问题 |
|---|---|---|
| 存储过程 | iBATIS对SQL进行了封装和外部化，使SQL从你的应用程序代码分离出来。iBATIS具有与存储过程相似的API，但是这些API都是面向对象的。iBATIS也完全支持对存储过程的调用 | 业务逻辑从数据库中分离开来，应用程序更容易部署与测试，也具有更好的移植性 |
| 内联SQL | iBATIS允许SQL以其最自然的方式书写。没有字符串拼接，没有参数“设置”，没有结果“获取” | iBATIS对应用程序代码没有任何影响，不需要任何预编译器，并且你能够完全访问SQL的所有特性。 |
| 动态SQL | iBATIS提供了若干特性以支持基于参数的动态构建查询。不需要“查询构建工具”这样的API | iBATIS不要求SQL被写成一堆字符串的拼接，中间还夹杂着应用程序的代码 |
| O/RM | iBATIS支持许多与O/RM工具一样的特性，例如延迟加载、连续抓取、告诉缓存、运行时代码生成以及继承 | iBATIS可用于任意数据模型与任意对象模型的组合。它对这两者中的任何一个的设计都没有任何约束和要求 |
接下来讨论iBATIS持久层所具有的两个最重要的特性：外部化SQL和封装SQL。
外部化的SQL
为了漂亮的分层设计（使得不同角色可以各司其职），外部化将SQL从引用程序的源代码分离出来，从而使得两者都更加清晰。这样保证了SQL语句与任何特定的语言平台都相对独立。以下SQL语句为例：
SELECT
PRODUCTID,
NAME,
DESCRPTION,
CATEGORY
FROM PRODUCT
WHERE CATEGORY = ?如果使用JAVA嵌入这样一个数据类型时：
String s = "SELECT"
+ " PRODUCTID,"
+ " NAME,"
+ " DESCRPITION,"
+ " CATEGORY"
+ " FROM PRODUCT"
+ " WHERE CATEGORY = ?";代码变得复杂以及难以管理，只要少个空格就会引起SQL错误。
iBATIS有最自然的书写SQL的能力：
SELECT
PRODUCTID,
NAME,
DESCRIPTION,
CATEGORY
FROM PRODUCT
WHERE CATEGORY = #categoryId#与之前SQL最大的不同之处在于参数的格式变成了#categoryId#，这个格式通常是特定于与语言的细节，iBATIS却使得它易移植且更具可读性。
封装化的SQL
封装的概念稍作扩展也可以应用到持久层中。可以通过定义SQL的输入和输出（例如它的界面）来封装它，这样的应用程序的其他部分就不需要知道具体的SQL语句。
iBATIS使用XML来封装SQL。之所以使用XML是因为它具有很好的跨平台性，并且得到了行业内的广泛使用，并且XML可能和SQL一样会具有很长的生命周期。iBATIS使用XML映射SQL语句的输入和输出。大多数的SQL语句都会有一个或更多的参数，会产生一堆表格后的数据作为结果。iBATIS允许你很容易地将输入输出映射为某些对象的特性。
<select id = "categoryById" parameterClass = "string" resultClass = "category">
SELECT CATEGORYID,NAME,DESCRIPTION
FROM CATEGORY
WHERE CATEGORYID = #categoryId#
</select> 通过以上的<select>元素定义了我们的语句的名字、输出参数类型以及输出结果类型。通过对此SQL封装，我们获得了简单性和一致性。
1.2 iBATIS适合的应用场景
iBATIS是一个持久层框架。持久层位于应用程序的业务逻辑层和数据库之间。以下介绍应用程序的各个层以及iBATIS与这些层的关系。
1.2.1 业务对象模型
业务对象是一个应用程序的所有其他部分的基础。它是问题域在面向对象方法学中的一种表现，因此构成业务对象模型的各个类也被称为领域类（domain class）所有其他层都使用业务对象模型来表现数据和执行某些特定的业务逻辑功能。
业务对象模型类中可以包含一些逻辑，但是它们决不能包含任何用于访问其他层(特别是表现层和持久层)的代码。并且，业务对象模型绝对不能依赖于其他任何一层，其他层可以使用业务对象模型 - 但绝对不能反过来。
1.2.2 表现层
表现层负责向最终用户展示应用程序的控制方式以及数据。它还要负责所有的信息的布局和格式。
目前，商业应用程序最流行的表现方式算是Web前端（如Amazon），而像Swing或者WinForms这样的富客户端能具备更强的用户界面。也有混合了Web应用程序与富客户端的”混合型客户端”（如Adobe Flex）。而混合型变现曾的典型案例就是AJAX,Asynchronous JavaScript and XML，异步Javascript和XML，但是它并不需要异步也并非只能使用XML，所以现在AJAX代表的仅仅是”一种基于Web的富客户端界面，由大量非常巧妙的JavaScrpit所驱动“。AJAX是使用旧技术构建内容丰富且交互性抢的用户界面的一种新方法。（如Google Mail/MAPs）。
iBATIS可用于Web应用程序、富客户端应用程序以及混合应用程序。虽然表现层不会直接与持久化框架”交流“，但是用户界面设计时某些决定也会影响对持久层的需求。比如一个Web引用程序需要处理5000条记录的大型列表，显然不能同时显示这5000条，此时好的解决方案如一次只加载10条记录。这样持久层就需要能够在返回数据的数量上允许一定的灵活性。甚至提供选择和获取我们希望的10条记录。iBATIS允许只查询某个特定范围内的数据，这样的特性就可以帮助我们达到以上这些目的。
1.2.3 业务逻辑层
应用的业务逻辑层描述了应用程序所能提供的”组粒度“的服务。正式这个原因，业务逻辑层中的类有时也被称为服务类。从较高的层次来看，任何人都应该能看懂业务逻辑层中的类和方法进而明白系统到底要做什么。
1.2.4 持久层
持久层是适合使用iBATIS的地方。持久层主要关注对象的存取。其次持久层需要关注的问题就是抽象，持久层应该隐藏关于数据如何被存储以及如何被取出的所有细节，这些I型街绝对不能暴露给应用程序的其他层。
我们将持久层又分为三层：抽象层、持久化框架以及驱动程序/接口层
抽象层
抽象层的目的就是在于为持久层提供一致且有意义的接口。它是一组类和方法的集合，这些类和方法是持久层实现细节的外观接口（facade）。抽象层中的方法不能使用特定于实现的参数，也不能返回特定实现专用的类或抛出特定实现专用的异常。一旦合适的抽象层准备就绪，整个持久化方法的改变都不再涉及抽象层，也不能引起任何其他依赖层的改变。许多模式可用于帮助实现一个合适的抽象层，其中最常用的就是DAO模式。
持久化框架
持久化框架负责与数据库驱动程序（或接口）的交互。持久化框架会提供用于存储、获取、更新、查找以及管理数据的方法。与抽象层不同，持久化框架通常只针对一类存储设施（比如XML,各种关系型数据库）。
驱动程序/接口层
软件驱动程序在底层与存储设施通信以交换数据。
1.2.4 关系数据库
iBATIS的存在就是为了简化对关系数据库的访问。数据库的确非常复杂，要正确地使用它们需要做很多的工作。数据库负责管理数据和修改数据。我们使用数据库而不简简单单地使用一个平板文件的原因就在于数据库提供了许多好处，比如数据完整性、性能、安全性。
数据完整性
数据完整性可能是数据库提供的最重要的好处，它通过使用强数据类型，强制约束，以及使用事物从而实现数据完整性的要求。
性能
关系型数据库比文件高性能的多，数据库性能可分为3个关键因素：设计、软件调整、硬件。
要提高数据库性能，首先要考虑的因素就是设计，糟糕的设计可能造成死锁、指数级关系运算或大量数据库表扫描。
对大型数据库来说，软件调整是第二重要因素，需要RDBMS软件的专业人士。调整的部分为：告诉缓存、文件管理、各种索引算法、操作系统。
安全性
关系数据库系统也提供了额外的安全性。我们在日常工作中使用的大量数据都是保密的。大部分商务性质的关系数据库都包括许多先进的安全特性，允许更细粒度的安全性以及数据加密。每个数据库都有其独特的安全需求，应用程序代码决不能削弱数据库的安全策略。
1.3 使用不同类型的数据库
并非所有的数据库都如此复杂，需要使用昂贵的数据库管理系统以及企业级的硬件。所有的数据库都是不一样的，它们有各自不用的需求和不同的挑战。iBATIS可以帮助你使用几乎任何类型的关系数据库。
数据库的划分更多是依据它与其他系统的关系，而不是依据其设计和大小。但数据库的设计和大小取决于它与其他系统的关系。另一个会影响数据库设计和大小的因素就是数据库的年龄。这里要讨论4种类型的数据库：应用程序数据库、企业数据库、私有数据库和遗留数据库。
1.3.1 应用程序数据库
应用程序数据库往往是最小、最简单、也最易于使用的数据库。应用程序数据库通常与我们的应用程序处于同一个项目中，两者一齐设计和实现。所以应用程序的设计往往存在很大的*度，也最有可能与我们的特定应用程序完美匹配。
应用程序数据库的对外影响是最小的，因为它通常只有一两个对外接口，第一个接口是我们的应用程序，而第二个接口可能就是一个简单的报表框架或报表框架（如Crystal Reports）。
应用程序数据库有时小到可以与应用程序直接部署在同一台服务器上。同样，使用应用程序数据库对硬件资源的要求也更加*。
MySQL或PostgreSQL就是典型的例子，有些应用程序甚至可能使用一种内嵌的应用程序数据库（hsqldb），这种数据库与应用程序运行在相同的虚拟环境中，因此连独立的SQL文件都可以不需要。
iBATIS能很好的支持应用程序数据库，对于简单数据库，有自动产生所有iBATIS SQL映射的工具可用。
1.3.2 企业数据库
企业数据库比应用程序库更大，其外部影响也更大。它们与其他系统之间存在更多的关系，包括依赖关系和被依赖关系,这些关系可能是Web应用程序与报表工具之间的，也可能是其他复杂系统与数据库的接口。
在企业数据库中，不仅仅存在远比应用程序数据库多得多的外部接口，而这些接口的作用方式也大不相同。一些接口可能是用于每晚批量加载数据的接口，其他的则可能是实时事物处理接口。由于这些原因，企业数据库本身可能实际上就由不止一个数据库组成的。
企业数据库对其设计和使用都强加了许多限制。对于数据完整性、性能以及安全性，企业数据库往往比应用程序数据库要考虑更多的因素。基于这个原因，企业数据库为分离关注点和分离需求，往往会分裂为多个部分。如果试图仅创建单个数据库来满足企业系统的所有需求，其代价将非常昂贵并且付诸，或者根本不实际甚至不可能。
iBATIS在企业数据库环境中工作得非常出色。它具有的一些特征使得它成为了与复杂数据设计和大型数据集协调工作的理想工具。iBATIS用于多数据库时同样出色，他同样支持在单个事物中涉及多数据库的复杂事物，实现报表系统和集成系统。
1.3.4 私有数据库
通常这样的数据库只允许只读访问，使用iBATIS时，可以限制运行的SQL的类别。当需求不允许数据库更新时，iBATIS绝不会对数据库执行任何神奇的更新操作。当需要更新的时候，私有数据库往往对数据的组织方式非常挑剔。iBATIS允许编写非常特定的更新语句已处理这种情况。
1.3.4 遗留数据库
遗留数据库往往是曾经的企业数据库，它们具有企业数据库的各种复杂性和依赖关系。此外它们还具有长期累月的各种修补与补丁。甚至，遗留数据库通常是在不仅已过时而且有时已完全不被支持的老式平台上开发出来的，对于现代的开发人员来说可能一家没有适当的驱动程序和开发工具可用了。
只要有合适的数据库驱动程序可用，iBATIS就可以像对其他任何数据库那样发挥作用。
1.4 iBATIS如何解决数据库的常见问题
1.4.1 所有权和控制
在现代企业环境里，数据库存在的第一个同时也是最主要的困难其实完全不是技术问题，而是大多数现代软件企业都将数据库的所有权和责任从应用开发团队中分离了出来。数据库通常都完全由企业中的一个独立小组所拥有。
数据库管理团队通常非常谨慎，数据库系统的变更控制流程通常都比应用程序代码的变更控制流程严格的多。数据库的某些变更可能会需要数据转移。其他一些变更则可能需要进行大量的测试以保证它们对性能不会造成影响。
当需要进行数据库设计以及数据库交互时，iBATIS通常能带来极大的灵活性，DBA可以直接维护iBATIS的SQL文件。iBATIS背地里绝对不会发生任何意想不到的事情，他们可以看到所有的SQL语句。
1.4.2 被多个分散的系统访问
也就是并发问题，一个数据库都不可能只有一个依赖者。
iBATIS作为持久化框架对所有类型的系统(包括事务系统、批处理系统还有报表系统)都是有用的。另外iBATIS可以使用分布或告诉缓存来在各个不同的系统之间进行通信。对于复杂情况，也可以容易地禁用iBATIS告诉缓存。
1.4.3 复杂的键值关系
iBATIS可以处理任何类型的复杂键定义和关系。虽然最好还是将数据库设计的更合理一些，但iBATIS的确可以处理那些使用无意义键、自然键、复合键甚至根本没有键的表。
1.4.4 数据模型的去规范化或过度规范化
数据模型中消除冗余的过程被称为规范化。
太多的表就需要创建太多的关系，以致难以维护。过度规范化的数据库会造成的问题包括：当查询数据库时，需要执行很多表连接操作；当更新关系紧密的数据时，需要执行很多更新语句。所有这些都会对数据库性能造成负面影响。当需要把这样的数据模型映射到对象模型时，通常也会更加困难，因为你可能不希望对象模型拥有与数据模型一样如此细粒度的类。
iBATIS对去规范化的模型和过度规范化的模型都是适用的。因为它没有对你的对象模型和模型粒度做任何假设，它也没有要求两者之间必须相同或者基本相似。iBATIS在分离对象模型和关系模型这件事上，恐怕是做的最好的了。
1.4.5 瘦数据模型
瘦数据模型时一种最为臭名昭著并且问题多多的对关系数据库系统的滥用。所谓瘦数据模型，就是简单的将每张表都设计为一种通用数据结构，用于存储名值对的集合。
典型的地址数据的示例：
| ADDRESS_ID | STREET | CITY | STATE | ZIP | COUNTRY |
|---|---|---|---|---|---|
| 1 | 123 Some Street | San Francisco | California | 12345 | USA |
| 2 | 456 Abitger Streat | New York | New York | 54321 | USA |
瘦数据模型中的地址数据：
| ADDRESS_ID | FIELD | VALUE |
|---|---|---|
| 1 | STREET | 123 SOME Street |
| 1 | CITY | San Francisco |
| 1 | STATE | California |
| 1 | ZIP | 12345 |
| 1 | COUNTRY | USA |
| 2 | STREET | 456 Another Street |
| 2 | CITY | New York |
| 2 | STATE | New York |
| 2 | ZIP | 54321 |
| 2 | COUNTRY | USA |
对于瘦数据类型，没有任何可能对它进一步规范化。其他没有任何机会创建关联关系，我们不能在同一个列上定义多个外检。其次查询，插入、数据量等数据库操作也很糟糕。
它的唯一用武之地就在于那些需要动态字段的应用程序。有些应用程序有这样的需求，允许用户对它们的记录添加额外的数据。
当一个企业数据库中遇到了瘦数据类型，iBATIS也可以帮助你处理它。要将若干个类映射为瘦数据模型时非常困难的，甚至是不可能的，因为你连数据模型中可能存在哪些字段都无法明确。此时最好将这样的类映射成散列表，而iBATIS支持这种映射。使用iBATIS，就不比将每一个表都映射为一个用户定义的类。iBATIS允许你将关系数据映射为基本类型、Map示例、XML还有用户定义的类，这种巨大的灵活度使得iBATIS对于包括瘦数据模型在内的复杂数据模型非常有效。
1.5 小结
iBATIS被设计为一个混合型解决方案，它并不试图解决所有的问题，相反，它只希望能解决哪些最重要的问题。iBATIS从各个数据库访问工具中汲取了大量的优秀思想。
像存储过程一样，所有的iBATIS语句都有一个签名，定义了语句的名字和输入输出(封装)。与内联SQL类似，iBATIS允许SQL语句按其最自然的方式书写，并且可以直接使用语言中的变量作为输入输出的请求动态构建。从O/RM映射工具中，iBATIS借用了许多概念，包括高速缓存、延迟假造，还有更高级的事物管理。
在一个应用程序的架构中，iBATIS适用于持久层。iBATIS也通过一些特性来支持其他层，如分页。
iBATIS可用于任何大小和用途的数据库。首先，iBATIS非常适合于那些叫嚣的应用程序数据库，因为容易和上手。其次、iBATIS对大型企业应用程序也非常合适，因为它没有对数据库的设计、行为或者那些可能对我们的应用程序如何使用数据库产生影响的依赖关系做任何假设。再次，即使对那些设计上有争议或者混乱的数据库中，iBATIS也可以工作的很好。
2、iBATIS是什么
- 何时使用iBATIS
- 何时不使用iBATIS
- 开始使用iBATIS
- iBATIS未来的方向
iBATIS到底是什么？
iBATIS就是我们通常所说的数据映射器 (data mapper)。
所谓映射器层，是用于在对象和数据库之间搬运数据，同时保证对象、数据库以及映射器本身都相互独立。
元数据映射正是适合使用O/RM工具的地方。O/RM工具将数据库表及其列映射为应用程序中的类及字段。或者说O/RM工具在数据库的元数据与类的元数据之间建立起了一种映射关系，类的每一个字段都被映射为数据库中唯一的对应列。
iBATIS与O/RM不同，它不是直接把类映射为数据库表或者说把类的字段映射为数据库列，而是把SQL语句的参数与结果（也即输入和输出）映射为类。iBATIS在类和数据库表之间建立了一个额外的间接层，这就为如何在类和数据库表之间建立映射关系带来了更大的灵活性。使得不用改变数据模型或对象模型的情况下改变它们的映射关系成为可能。这里的间接关系就是SQL。
O/RM关系映射：
iBATIS的SQL映射：
如上图，iBATIS的映射层其实就是SQL。iBATIS让你编写SQL语句，负责在类的特性和数据库的表之间映射参数和结果。因考虑到其他各种各样的映射方式的区分，为避免混淆，iBATIS团队通常将所谓的“数据映射器”称为SQL映射器（SQL mapper）。
2.1 映射SQL语句
任何一条SQL语句都可以看做是一组输入和输出。输入即参数(parameter)，通常可以在SQL语句的WHERE 子句中找到。输出则是SELECT 子句中指定的那些列。
iBATIS使用了一个简单的XML描述符文件来映射SQL语句的输入和输出。代码示例：
<select id = "getAddress" parameterClass = "int" resultClass = "Address">
SELECT
ADR_ID as id,
ADR_DESCRIPTION as descrption.
ADR_STREET as street,
ADR_CITY as city,
ADR_PROVINCE as province,
ADR_POSTAL_CODE as postalCode
FROM
WHERE ADR_ID = #id#
</select>从<select>元素中可以看出该语句使用了一个Integer对象作为参数，该参数是通过WHERE子句的#id#符号标记的。还可以看出该语句的结果是一个Address类的对象示例。如果Address类中的所有字段名与SELECT语句中指定的各个类的别名（通过as关键字）相同。JAVA执行代码如下：
Address address = (Address) sqlMap.queryForObject("getAddress",new Integer(5));2.2 iBATIS如何工作
iBATIS在后台也是运个性几乎相同的JDBC代码 - 获取链接、设置参数、执行语句、获取执行结果、在最后关闭所有的资源。
而程序员亲自编写的代码量大大的减少了，只需要一份SQL映射的XML以及一行运行代码（如上）。
2.2.1 iBATIS之于小型、简单系统
小型应用程序通常只涉及单个数据库，只有一些相当简单的用户界面和领域模型。iBATIS非常适合于小型应用程序，有3个原因：
第一，iBATIS本身就很小并且很简单。它不需要服务器或者其他类型的中间件、不需要额外的基础设置。没有第三方依赖，只需要2个JAR文件，总计不过375KB。除了需要配置几个SQL映射文件外，iBATIS不需要进行任何其他安装。
第二，iBATIS不会对应用或者数据库的现有设计强加任何影响。
2.2.2 iBATIS之于大型、企业级系统
iBATIS最初就是为了企业级应用程序而设计的。iBATIS适合企业应用环境的特征。
- iBATIS没有对数据库模型或对象模型的设计做任何假设。
- iBATIS的某些特征使得它能够非常高效的处理大型数据集。 iBATIS支持的行处理器(row handler)使得它能够批处理超大型记录集（一次一条记录）。iBATIS也支持只获取某个范围内的结果，这就使得你可以只获取那些你当前需要的数据。
- 最后一点，iBATIS允许你用多种方式建立从对象到数据库的映射关系。一个企业级系统只以一种模式工作的情况是非常少见的。许多企业级系统需要白天执行事务性的功能，而晚上执行批处理功能。iBATIS允许你将同一个类似多种方式映射，以保证每一种功能都能以最搞笑的方式执行。iBATIS同样支持多种数据获取策略，例如延迟加载。
2.3 为何使用iBATIS
几乎可以在任何系统中使用iBATIS，像iBATIS这样的框架能够使我在应用程序从架构级别上受益。
2.3.1 简单性
iBATIS被广泛认为是当今可用的最简单的持久化框架之一。简单性的理念根植于iBATIS开发团队，它在iBATIS的所有开发目标中居于首位。
2.3.2 生产效率
iBATIS在给开发人员带来更高的开发效率方面做得非常成功。iBATIS省略了大量的JDBC API代码。
2.3.3 性能
框架必然会带来一定的性能损失，JDBC要比iBATIS在性能上具备一定优势。但是iBATIS一些功能会大大的提高性能，比如分页，延迟加载。iBATIS支持许多性能优化措施，并且配置简单以及实用。
2.3.4 关注点分离
iBATIS通过帮助管理所有持久化相关资源来支持分层，这些资源包括数据库连接（Connection）、预处理语句（prepared statement）以及结果集（result set）。iBATIS提供了一组数据库五官的接口以及API，使得应用程序的其他部分与持久化相关资源五官。
2.3.5 明确分工
iBATIS使得分工称为可能，SQL程序员可以按照SQL原本的方式编写iBATIS。
2.3.6 可移植性
目前（iBATIS in Action 发布的时候），iBATIS支持3种最受欢迎的开发平台：Java、Ruby和.NET的C#。
2.3.7 开源和诚实
iBATIS是免费的开源软件。
2.4 何时不该使用iBATIS
iBATIS是一个中层的框架。它比JDBC的层次高一些，但相对于O/RM工具，层次又要更低。
2.4.1 当永远拥有完全控制权时
如果能够保证拥有对应程序设计和数据库设计的完全控制权（数据库的控制权在应用小组手里，而不是DBA），就有充分理由使用一个完全的O/RM解决方案，比如Hibernate。
2.4.2 当应用程序需要完全动态的SQL
如果应用程序的核心功能是动态生成SQL，那么不能使用iBATIS。
2.4.3 当没有使用关系数据库时
对于关系型数据库，如XML,平板文件以及其他，不推荐使用iBATIS。
2.4.4 当iBATIS不起作用时
当iBATIS的功能和应用程序的需求发生冲突。
2.5 5分钟内用iBATIS创建应用程序
2.5.1 安装数据库
iBATIS框架可以使用任何数据库，只要该数据库具有符合规范的JDBC驱动程序。只需要在配置文件提供驱动程序的类名以及一个JDBC URL。
如果安装了一个不同数据库服务器，其中包含了一些你想要在其上执行某些SQL查询的其他数据，需要修改SqlMap.xml中的查询语句，另外修改SqlMapConfig.xml文件以配置iBATIS从而使用你的数据库。
2.5.2 编写代码
一个简单的demo：
import com.ibatis.sqlmap.client.*;
import com.ibatis.common.resources.Resources;
import java.io.Reader;
import java.util.List;
public class Main{
public static void main(String[] args) throws Exception{
String resource = "SqlMapConfig.xml";//iBATIS 配置文件
Reader reader = Resources.getResourceAsReader(resource);
SqlMapClient sqlMap = SqlMapClientBuilder.buildSqlMapClient(reader);
List list = sqlMap.queryForList("getAllUsers","EMPLOYEE");
System.out.println("Selected ") + list.size() + " records.");
for(int i = 0 ; i < list.size(); i++)
System.out.println(list.get(i));
}
}