最近工作了,也发现了自己曾经认识中的一些误区,在 工作中慢慢的体会,慢慢的提升。
随着系统越来越庞大,为了让系统层次清晰,大家习以为常的为系统进行分层处理,现在很流行的也是三层架构,也就是常见的数据访问层(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:以上是个人在学习中的一点点小认识,比较浅薄,如果有些错误的地方,请大侠们指点,帮助我纠正提高。