DAO层

首先，以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外面，实现事务的管理。

对于事务这边的东西，去放到业务逻辑层好了~