废话一翻后，进入今天的正题。今天的主题是Introduction，非官方正式介绍的中文版，更多详细的介绍请参阅官方文档。我们要使用它就必须要知道它是干什么用的，能为我们做哪些工作，开发效率如何，执行效率如何，技术难度怎么样。
提到iBatis，大家可能会与ORM技术联系起来。是的，没错，它与ORM技术有一定程度上的联系，但是更确切地讲，它并不是一种很正统的ORM解决方案。因为它不像NHibernate那样，具备全自动的数据操作，包括查询，插入，更新，删除；
也没有像它那样，与数据库的约束关系有紧密的联系（对NHibernate的了解不多，如果有不妥之处，希望能留下你们的臭鸡蛋，等着下回用）。iBatis为我们提供了一种更为灵活的方便的可控的方式去实现类ORM的解决方案。我们需要自己来控制SQL语句，这样做有好处在于，我们可以更灵活地根据我们的需求，编写更加具备性能，功能优势的SQL语句，但它的缺点同样明显，我们还是需要管理和编写SQL语句。但是值得感到高兴的是，我们只需要提供这些SQL语句，和为它提供它所需的参数外，接下来的事情就无需我们参与了。这也是iBatis最核心的功能，也是它为我们所做最多的工作了。根据配置好的SQL语句和参数条件，它会动态生成一条可执行的SQL语句，然后根据具体传进来的参数值，为这些SQL参数提供不同的具体值。然后根据配置好的数据访问驱动，自动为DbCommand添加DbParameter，自动执行SQL语句，使用IDataReader返回出数据集，生成并返回一个或多个强类型数据类对象（数据集用IList集合对象表示）。我曾经在Community Server中也见过类似的返回强类型数据对象的实现，但是需要很多的代码，与直接返回DataTable相比，重复代码会更多。所有的这些在iBatis中，只需要提供一个配置文件，调用它提供的SqlMapper实例对象中的方法就可以很简单容易地实现了。当然你也许会说，那这样如果系统比较大的话，可能就需要很多的配置文件了。是的，又陷了另一个极端了。怎么办呢没办法，鱼和熊掌不能兼得啊。这里还不得不重点强调一下，如果你是经常在存储过程中拼接SQL语句的话，那我就更加推荐你马上就开始使用iBatis吧。
提到数据操作，就不能不提到数据的安全性和完整性问题了，也就是数据操作的事务问题。如果你是直接使用A进行事务操作的话，那您可能需要写更多的代码了，当然我们可以使用Enterprise Library来简化我们的工作。那现在通过一段简单的代码也看一下在iBatis中该如何实现事务吧 using IDalSession session sqlMap.BeginTransaction { Item item Item sqlMap.QueryForObject“getItem“, itemId; item.Description newDescription; sqlMap.Update“updateItem“, item; session.Complete; // Commit } 就这么简单的代码，它就会帮我们自动管理事务了。这期间如果出现异常，我们仍然可以捕获到异常信息。
OK,通过上面的介绍，我们已经能够了解到一个大概了。总结一下，它帮我们自动管理和执行SQL语句，并且返回强类型的数据对象。从上面的一段简单的代码中，你可能已经感觉到了它的使用有多么的简单并且如果需要的还能够返回生成的DbCommand，支持我们通过它返回DataTable或者其它的Ado操作返回。但是，这时你会马上产生另一个疑虑了，我们的工作还是很多啊，比如编写数据类和配置文件，可能工作量并不亚于直接使用A返回DataTable所写的代码，并且会更加的没有技术含量。所以，对于这些的代码，我们尽量能通过一些代码生成工具（我是使用CodeSmith）自动生成大部分，然后再根据我们需要进行修改。
再来看看执行效率吧，尽管iBatis或多或少用到反射技术，但由于使用配置文件的形式，性能影响已经降到最低了。我曾经做过一个测试，用它添加多条记录和使用UpdateDataSet成批提交数据相同的数据的方式进行过比较，总体时间效率不会更差，反而会更快一点。
最后不得不再提一点，它的缓存机制做得很好，相同的SQL语句，可以根据不同的条件值，缓存用这个条件执行查询时的输出数据。它的缓存过期策略是封闭的。详细细节，相信随着深入会有所涉及。
对它的介绍就先告一段落了，下一篇将会首先介绍一下它的配置工作环境，重点在于介绍如何使用log4net记录日志。
iBatis.Net系列2 配置运行环境和日志处理 现在我开始介绍一下iBatis的配置和日志处理吧。
iBatis基本的运行环境配置主要由两个文件组成，分别是SqlMap.config和Provider.config。它们是必需的两个配置文件，基中SqlMap.config的功能类似于web.config或者app.config，是iBatis核心的配置文件，它的存放路径也跟应用程序配置文件一样，必须放在应用程序的运行目录下并且它的文件名是保留的，不可改变的。而Provider.config是一个数据驱动提供类的配置，它的文件名是可以随意改变的，因为通过SqlMap.config的一个配置节可以配置它的引用。
SqlMap.config包括以下一些主要的配置节，根据需要，有的配置节并不是必须的 1. properties 可以根据需要配置一些常量属性。如果这些属性有很多的话可以单独写一个文件里面，再通过resource（或url, embedded分别是引用url和编译在程序中的资源文件）属性引用进来。如 这个配置节是可选的。
2. settings包括有三个配置段 useStatementNamespaces在文档中说明它的作用是配置在使用语句ID的时候要不要加命名空间，例中{useStatementNamespaces}就是使用properties中的一个属性，默认是false。
cacheModelsEnabled 是配置要不要启用iBatis的缓存模型，默认是true。
validateSqlMap 是配置要不要启示验证映射文件，默认是false。
3. providers 配置数据驱动提供类配置文件的路径和文件名。
4. database 数据库的信息，包括使用哪些数据库驱动和数据连接字符串的配置。
5. alias 类型别名的配置，为了使用更方便的使用类（类名更短），就需在这里进行别名的配置。
6. typeHandlers 这个就相对比较复杂些了，到目前我也没有使用到。从字面上理解，它是一个类型的处理器，它的作用是当你使用的数据库当中有iBatis不支持或不认识的字段（或者不希望默认的处理方式），那就可以为它取一个名字，并且指定对应的.NET类型来处理它。
7. sqlMaps 用来包含当前已经写好的，并且需要用到的数据类映射文件。
以上就是Sqlmap.config的基本内容了。注意，以上凡是涉及到引用外部文件的都支持resouce，url，embedded 三种方式。
Provider.config的配置类很简单，在默认的Provider.config中已经有很多不同数据库的数据驱动，而在SqlMapp