首先，以JDBC为基础，开始思考这个问题。
在查询一个用户信息（id，name）的时候，我们常常是这么操作的：
1. 获取一个connection
2. 生成一个statement
3. 拼接SQL语句
4. 查询对象，获取结果集（假设已经找到我们需要的对象）
5. 读取结果集信息，封装成需要的用户对象
6. 关闭结果集，statement，connection
其次，考虑一下Hibernate怎么处理？
1. 建立用户信息对象，并配置好对象关系映射
2. 获取一个Session对象
3. 生产一个Query对象
4. 编写HQL语句
5. 执行Query.list()方法，获取对象信息（这里Hibernate框架根据映射关系，完成对象与关系之间的转换）
6. 关闭Session对象
细细看来，其实，他们处理都是基本相同的，只是不同的就是在进行封装过程中，略有不同了。
那么我们来看一下Ibatis是如何处理的，
1. 编写PO对象，配置sqlMap文件
2. 生成SqlMapClient对象
3. 操作对应的SQL，返回结果（sql语句，我们写的配置文件中，对象封装由Ibatis框架完成）
4. 关闭SqlMapClient
DAO层处理的应该是对象关系相互转换的工作，它需要的是一个连接对象，但是它不关心这个对象怎么来，而且不关心在转换工作完成后，做怎么样的处理。就像Ibatis框架似的，它在项目就充当着DAO的作用，因为我们通过配置文件和实体对象我们已经完成了对象关系的转换。而针对JDBC和Hibernate技术，我个人觉得，我们可以把一个连接作为参数传递到DAO，以避免我们为DAO的每个方法中都获取一个连接对象，这样我们就可以不用在DAO中处理数据库连接的打开和关闭了，从何在DAO外面，实现事务的管理。
对于事务这边的东西，去放到业务逻辑层好了~