三层架构新观点

三层架构新观点2011-04-05 博客园私家侦探乱用三层的项目

现在三层太流行了，我想至少50%稍微有些规模的项目都是采用三层.本人也开发了几个三层方面的项目,总算见识了不理解三层就开发三层带来的恶果.

什么是稍具规模的项目,以我开发的项目为例吧,（借此把开发过的项目宣传一下,sorry）

如www.ungou.com/ http://www.yinggou.com/ http://www.doocn.com/

说真的,我无意宣传,也没有这个脸,因为这三个项目都算是三层方面的失败者（因为我不是项目中的老大）,带来的后果我不说大家也知道:混乱,维护难.

三层新观点

数据访问层

1.数据访问层不应该有事务,应该只是很纯的增,删,改,查询,是否存在等等比较通用的数据访问方法.

2.业务需求的变化不应该造成该层方法的修改（除非是增加字段等等和表有关联的需求） ,判断是否合格的数据访问层可以使用这条规则.

3.数据访问层中的方法对于业务层来说是一个个很纯的小零件（或者说积木吧）,举例说吧,一个添加用户的方法中,就只是添加用户,不会再向日志表插入操作日志.这样做的好处是方法职责清晰,稳定（能适应需求变化,一经代码生成后,很少再做修改,就叫做稳定）

4.数据访问层的方法中并不是说就完全没有事务参与,经常是要先判断当前线程上下文是否有事务存在,有事务存在就按事务执行,没有事务就自己创建连接对象.

业务层

1.最主要的任务是按业务需求组织调用数据访问层中的方法,就好像搭积木一样,搭积木可以有很多花样,正如业务需求也是一样花样很多.具体举例说:在业务层中添加用户方法中可能是这样:

开始事务

插入用户

插入操作日志

提交事务

2.大部分业务需求的变化应只要修改业务层中的代码即可,比如上面添加用户的需求变化了,要求添加用户时能分配角色,上述方法就变成是这样:

开始事务

插入用户

插入用户角色表（用户id）

插入操作日志

提交事务

表现层

暂不谈

基于这种设计的数据层和业务层优点

1.由于数据访问层的方法就像积木一样,粒度很低,很通用,可以代码生成,业务变化基本上也不会修改改层代码,很稳定很好.

2.业务层代码很灵活,都是一些核心的业务代码.代码量比数据访问层多很多.经常听到或看到很多人都说"三层代码中的业务层就好像一个转发器一样,没什么代码,把数据访问层的方法转一下就完成任务了,好像是多余的一个层",这种说法在j2ee项目中一样经常存在,虽然j2ee项目一向被世人认为大部分是比较规范化的,（net项目经常被人说代码很乱,很有地方特色,每个人有每个人的写法,哈哈）.