myBatis ->半自动化的ORM 框架

1:myBatis ->半自动化的ORM 框架
前身 iBati

myBatis 灵活方便 轻量级的ORM 框架

configuration 配置信息
environments 应用程序的环境
如果一个应用程序对应多个数据库就需要配置多个环境

environment 单个 环境的配置信息

transactionManager type=”JDBC” 事务管理机制
type=”JDBC|MANAGER”
JDBC 采取jdbc事务机制 默认自动提交
Connection
.setAutoCommit(true|false)
MANAGER 采取容器管理

数据源
type=”POOLED” 使用mybatis自身自带数据连接池
type=”UNPOOLED” 直接的jdbc 不用连接池
type=”JNDI” 用户自身配置的 数据连接池

select * from zt_proudce where id=#{id}

{id} 代表一个占位符 -> jdbc ?

id 代表字符串拼接

原理:要有一个 Configuration.xml的配置文件，里面配置好数据库连接的基本信息，数据源等，然后通过mappers标签将dao类操作的配置文件加载进来，dao配置文件中封装用select ，insert，update等标签封装好对类的添删改查方法，最后就可以直接测试调用了，在测试类中通过一个Reader对象接收到读取的Configuration.xml的配置文件信息，创建出SqlSessionFactory和SqlSession后，用dao类的对象接收session读取到的类文件信息，就可以用dao对象来调用方法了
Mybatis：
1：使用连接池，datasource，在驱动并连接的这个过程中优化并解耦
JDBC第一步其实从效率角度来看是不合适的，因为无论什么数据库都不可能支撑随机和庞大的连接数，而且不可避免的存在连接浪费的情况，Mybatis就封装了这些优化的方法。

2：统一sql存取到XML
如果代码写在java块中，在团队合作中很可能出现两个交叉业务的代码使用类似的sql语句，而开发人员的工作本身没有交集，那就代表sql语句肯定是无法复用的。而且对sql的修改，就代表着对java文件的修改，需要重新编译和打包部署（比如常见的状态值更改，sql修改随着业务变化必然存在修改）。
mybatis将sql统一存取到xml中，就算存在业务交叉，但因为统一配置的缘故，sql在xml中一目了然，两个跨team的程序员可以看到对方的sql，来判断自己是否需要重用。并且使用xml配置可以减少代码编译。
还有就是在java中拼写长sql太恶心了。
3：参数和结果集映射
sql的方式需要传入参数，如果存在多条件“或类型”的查询（列表查询的查询条件允许空），那就代表你必须传参进行sql拼接，就算使用xml的方式也不行。要么每个业务独立配置xml中的sql，要么还是写入java代码中，或者以工具的方式进行自动拼接。
Mybatis使用映射的方式，方便model管理参数，同时以解析器的方式将参数动态拼接到sql（sqlmaper里那些标签），由于是model映射，连查询结果都可以统一映射，方便取出和运算。而且mybatis对查询结果集进行了缓存处理，使得重复查询进一步进行了优化。
4：对多重复sql进行复用封装

比如模板方法，将常用sql模块化，直接调用。比如通用的save和getID之类的，只有表名和字段名有变化。