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