DAO层与Business层之间的关系

最近工作了，也发现了自己曾经认识中的一些误区，在 工作中慢慢的体会，慢慢的提升。

 

随着系统越来越庞大，为了让系统层次清晰，大家习以为常的为系统进行分层处理，现在很流行的也是三层架构，也就是常见的数据访问层（DAO），业务逻辑层（Business），表现层（UI）。在表现层中又常常会采用MVC模式，即Model-View-Controller。针对着不同层次结构，在相互访问操作中，用到了很多对象，比如DTO（Data Transfer Object），BO（Business Object），PO（Persistence Object）等等。

 

一直以来，我采用三层架构，但却不曾知道它真的用意（当然现在的认识也很浅显）。直到在大四下学期中，在软通动力实训的时候，孙旭博老师给我们讲DAO层的作用的时候，我一直以为DAO就是完成对象关系任务的对象。当然，DAO层完成的也的确是对象关系数据的相互转换。但是，从松耦合的角度来说，把业务逻辑相关的信息硬生生的写到了DAO层，没有使底层的架构与上层脱离关系，使得DAO层与Business层紧紧的贴住了。不知道大家在DAO层中写没写过这样或者类似的方法，就是登录时验证用户身份的方法。其实，这在个方法中，我们完成了一个DAO和一个业务逻辑，DAO就是到数据库中根据用户名和密码获取一个用户，而业务逻辑就是，看看这个用户是不是存在（当然，这个业务逻辑比较简单）。因为简单的逻辑让这个设计并没有什么太大的问题，那么当我们在一次中需要同时向三个表里插入记录的时候，那么我们就要使用到事务，那么我会在DAO层开始和关闭事务，大家想想这个是不是加大了DAO层的压力。

这样的DAO:

1. 获得一个connection

2. 生成一个statement

3. 写一句SQL，放入statement中

4. 执行statement

5. 关闭statement和connection

6. 返回结果

 

DAO层犹如一个管道，它只负责联通就好了。让它怎么去通到业务逻辑处实现就好了。所以把事务加到业务逻辑层中，这样呢，就需要我们对上面的DAO层对象做一下修改：

修改后的DAO:

1. 向DAO中注入一个connection

2. 生产statement

3. 写SQL，放入statement

4. 执行statement

5. 返回结果

把statement和connection的关闭放到业务逻辑层中，这样，我就可以在执行一个操作的过程中，操作多个DAO，而不用担心它开启和关闭，拒绝访问等问题了。

 

最后我还想简单说一下，在面向对象的编程中，有很多对象，记起来挺麻烦的，如果理解了就比较容易了，因为它们都是与层次结构相互关联的。

PO，是针对关系与对象映射的，用在DAO层访问中

BO，是业务逻辑的对象，处理业务的时候使用的

DTO，其实这个对象是用在由服务器跟客户端交互的时候，传输数据时候用到的

 

 

PS:以上是个人在学习中的一点点小认识，比较浅薄，如果有些错误的地方，请大侠们指点，帮助我纠正提高。