IBATIS开发指南(夏昕)

  相对于Hibernate Apache OJB一站式ORM解决方案而言,ibatis是一种半自动化ORM实现，所谓半自动化可能理解上有些生涩。纵观目前主流的ORM,无论是Hibernate还是Apache的OJB,都对数据库结构提供了完整的封装，提供了从POJO到数据库表的全套映射机制。程序员往往只需定义好从POJO到数据库表的映射关系，就可通过Hibernate或者OJB
  提供的方法完成持久层操作，程序员甚至不需要对SQL熟悉，Hibernate/OJB会根据制定的存储逻辑，自动生成相应的SQL并调用JDBC加以执行。
  大多数情况下(特别是新项目，新系统的开发而言)这样的机制无住不利，大有一统天下之势，但在特定的情况下，这种一站式未必灵光。
  在笔者的经历中，常常遇到以下情况：
  1系统的部分只用现有的数据库，处于安全考虑，只对开发团队提供几条SQL语句或存储过程来获取数据，具体的数据不予公开。
  2开发规范要求，所有涉及到业务逻辑的数据库操作，必须在数据库层由存储过程实现。
  3系统处理的数据量巨大，性能要求极为苛刻，这往往意味着我们必须经过高度优化的SQL才能达到设计要求指标。
面对这样的要求，再次举起Hibernate的大刀发现在刀锋已不利，甚至无法使用，奈何，恍惚之际，只好准备JDBC准备拼死一搏.......,说得未免有些凄凉，直接使用JDBC对数据库操作是个不错的选择，只是拖沓的数据库访问代码，乏味的读取字段令人厌烦。
   半自动化的ibatis刚好解决这个问题.
   这是里的半自动化，是相对于Hibernate的数据库提供的全套封装机制全自动化ORM实现而言，全自动 ORM实现了POJO和数据库表之间的映射，以及SQL的自动生成和执行。而ibatis的着力点，则在于POJO和SQL这间的映射关系。也就是说ibatis不会为程序
   员自动生成SQL招行。具体SQL要程序员自己编写，然后通过映射配置文件，将SQL返回的参数，以及返回的结果字段映射到指定的POJO。
  使用ibatis提供的ORM机制，对业务逻辑实现人员而言，面对的是纯粹的JAVA对象，这一层与Hibernate通过的ORM实现而言基本相似，而对具体的数据操作，Hibernate会自动生成SQL语句，而ibatis则要求程序员自己编写SQL语句，相对于Hibernate全自动
  映射机制而言，ibatis及SQL开发的工作量和数据库移植上做出了让步，为程序设计提供了更大的自由空间，作为ORM全自动的机制的有益补充，显得别具意义。
1 ibatis典型配置实例
   <?xml version="1.0" encoding="gb2312" standalone="no"?>
   <!DOCTYPE sqlMapConfig SYSTEM "http://www.ibatis.com/dtd/sql-map-config-2.dtd">
   <sqlMapConfig>
<settings cacheModelsEnabled="true" enhancementEnabled="true"
maxSessions="228" maxTransactions="128" maxRequests="1000" />
<transactionManager type="JDBC">
<dataSource type="SIMPLE">
<property value="${driver}" name="JDBC.Driver" /> JDBC驱动
<property value="${url}" name="JDBC.ConnectionURL" /> 加载数据库URL
<property value="${username}" name="JDBC.Username" /> 数据库用户名
<property value="${password}" name="JDBC.Password" /> 数据库用户密码
<property name="JDBC.DefaultAutoCommit" value="true" />
<property value="${MaximumActiveConnections}"
name="Pool.MaximumActiveConnections" /> 数据库连接池可维持的最大容量
<property value="${MaximumIdleConnections}"
name="Pool.MaximumIdleConnections" />
<property value="${MaximumWait}" name="Pool.MaximumWait" /> 数据库连接池中允许的挂起(idle)连接数
<property name="Pool.MaximumCheckoutTime"
value="${MaximumCheckoutTime}" /> 数据库连接池中，任务被某个连接所占用的最大时间，如果超过这个限定，连接将会被强制收回(毫秒)
<property name="Pool.TimeToWait" value="${TimeToWait}" />  当线程试图从连接池中获取连接时，连接池中无可用连接使用，些线程进入等待状。
                                                                                   直到池中出现空闲连接，此参数设定了线程所允许等待最长时间
<property name="Pool.PingQuery"
value="select 1 as ISPINGWORKING from dual" />  数据库连接状态检查语句
<property name="Pool.PingEnabled" value="${PingEnabled}" />  是否允许连接检测状态
<property name="Pool.PingConnectionsOlderThan"
value="${PingConnectionsOlderThan}" /> 对持续连接时间超过设定值(毫秒)连接进行检测
<property name="Pool.PingConnectionsNotUsedFor"
value="${PingConnectionsNotUsedFor}" /> 对空闲超过设定值(毫秒)的连接进行检测
</dataSource>
</transactionManager>
       <sqlMap resource="sqlmap/sql/test.xml" />
  </sqlMapConfig>

  cacheModelsEnabled="true"  是否启动缓存机制
  enhancementEnabled="true"  是否针对POJO启动字节码增强机制以提升getter/setter的调用效能避免使用javaReflect所带来的性能开销。同时Lazy Loading带来极大的性能提   升。
  maxRequests最大并发请求数(Statemetn数)
  maxTransactions最大并发事务数
  maxSessions最大Session数，即当前最大允许的并发SqlMapCliect数maxSessions设定必须界于maxTransactions和maxRequests之间.即   maxTransactions>maxSessions>maxRequests

这样也行？夏昕的拿来就抄了，还原理解析？I服了You！