谈分层：业务逻辑层不是转发器

在Java EE的开发中，我们一直强调分层，什么MVC三层体系，N层架构，好像只有分的层越多，系统就越完美，才能体现出现代软件工程的优点。最近一直在思考，我们为什么要分层？分层的意义何在？怎样去组织各个层次的关系？

       分层的好处就在于代码清晰，结构分明，有利于修改、维护和复用，这已经成为大家分层的一个最有说服力的原因。但是也并不是任何系统都要分层设计，简单的系统，可以选择较少的层，反而可以开发效率和系统运行的效率。特别在需求不断更新和未知的web开发中，分层也并不能给我们带来多少实质性的好处，反而增加的复杂度而不能及时响应需求。

       但在大型的企业级开发中，我们通常要进行分层设计，而表现层、业务逻辑层、数据操作层是我们最普遍的层次划分，如下图所示。在表现层上，我们已经习惯了MVC的体系，常使用Struts，JSF等框架。而在MVC的体系中C是其中的核心，我们在这里用Action来表示，它处理客户端发送的请求并根据业务的流程进行转发。而实际的业务处理，则交给Service处理。我们常使用Spring、EJB去做这一层的架构。而数据持久层，JPA的标准，Hibernate、Toplink等ORM框架已经被我们越来越多的使用。

在分层体系中，我一直在思考，谁才是核心，哪一层才是系统最关注的部分。当然大家都很明白，业务才是系统核心，一切随业务的变化而改变。但是在实际的开发中，我却看到很多这样的现象，包括发生在自己身上的。我们过多的关注了表现层和DAO层，业务的变更最直观的体现是表现在页面上，表现层的变化是必须得，但是表现层的变化更多的体现在流程的变化。我们也经常喜欢去过度的处理DAO层，业务的变更直接体现到SQL上的变更，一个个业务逻辑被翻译成一条条复杂的SQL语句。而这些导致的结果是什么，Service层成为可有可无的鸡肋，它存在的意义完全成了连接Action和DAO的简单桥梁。以下代码确实反映了这个问题。

public A saveA(A a){

       return this.aDAO.saveA(a);

}

public List<A> getAs(String a,String b){

       return this.aDAO.getAs(a,b);

}

……

我们在开发的时候，虽然划分了Service层，但是这只是对DAO的简单调用，Service成了绝对的轻量级。有时候页面上需要一个几十行的list，只是由于分成了几块展示，而我们经常按照这几块去一次次的查询数据库，而不去试着让Service调用一次数据库取到所有的记录，然后通过一定得策略去分解这些记录。难道企业的开发只是数据库的操作？Java的运算性能难道只体现在SQL的优化上？这样的分层还不如不分，业务层也没有必要。

还是让我们回归Service的本来面目吧，让我们将action和DAO的部分功能向Service转移吧。Action只负责接受请求，调用具体的Service，进行处理后转发；DAO可以使用更精简的，更通用的方法处理所有数据的持久和查询，只需要封装最基本的增删改查就OK了。让Action和DAO尽可能的轻量级，只关注本身，而非业务。让业务层来处理更多的内容吧。如下是业务处理的方法。

public void saveA(A a){

//保存前某业务逻辑的验证，如数据合法性检查，业务规则验证

       this.aDAO.saveA(a);

       //保存完想JMS发送消息，通知用户已经处理

}

有人认为分层不好是因为一个地方改变，需要维护好多层，其实这是没有有效的使用分层，DAO和action层存在了过多的业务逻辑的处理，业务的改变当然会造成动一处而牵全身的后果。关注Service层，解放action和dao，保持action和dao的高度稳定性，利用稳定的业务接口和IoC等松散耦合的处理进行层层的交互，让程序人员更多的关注业务本身，而非其他的繁枝末节，这才是我们分层的目的。

但是在开发中的确面临着这样的问题，除了复杂的业务逻辑，Service中必不可少的需要简单的增删改查的简单调用，怎样才能让Service从中解放出来，让我们更多的关注真实的业务操作，这是下次要思考和讨论的问题。

 

原文：

http://www.po-soft.com/blog/yongtree/122.html

评论

10 楼 yongtree 2009-05-18  

david2083 写道

不要为了分层而分层,把你预期会经常变化的地方独立出来就好了,框架的功能就是隔离变与不变

同意该观点，合理的使用框架，也是架构能力之一。

9 楼 湖南陈冠希 2009-05-18  

其实这个还是需要时间的积累的,接触多了感触就越多......

很多人开发了几年JAVA,可能只是写代码很熟练,但架构能力不行.

8 楼 david2083 2009-05-18  

不要为了分层而分层,把你预期会经常变化的地方独立出来就好了,框架的功能就是隔离变与不变

7 楼 yongtree 2009-05-18  

}
……

sky726 写道

是很有道理，但小弟对这篇文章有几个疑问 表现层、业务逻辑层、数据操作层&nbsp; 各司其职是没错， 但以本篇文章的观点，这是不是太硬性了？ 怎么让我感觉是为了分层而分层呢？ 您在文章中也说了“简单的系统，可以选择较少的层，反而可以开发效率和系统运行的效率。” 那么，为了实际需要、或提高效率而让某一层做了本不该是这一层做的事，是不是也可以谅解呢 用本文的一个例子，service 中这样写到: public A saveA(A a){ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return this.aDAO.saveA(a); } public List&lt;A&gt; getAs(String a,String b){ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return this.aDAO.getAs(a,b); } …… 但是就拿分页来说，像我一般的做法就是在dao那写一个执行分页的sql语句(或存储过程)的方法,service调用dao,传几个参数，OK。于是就产生了类似上面的这些代码。 其实很多时候我们也不想这样写的，按照LZ的说法，dao把所有的数据查询出来，再在service层那处理分页，当数据量很大时，那请问效率是不是比我的做法低很多呢??? 相信很多人也有这样想过吧。 看语气感觉LZ对分层很执着呢，不过没什么特殊原因业务却又写在dao里边的，相信也大有人在，不然LZ也就不会写这篇文章了，纯属个人观点，本人经验尚浅，就分页这个问题，如果有什么方法即能不违背分层的目的，又能比我那样的代码效率的，还请赐教。

多谢参与讨论，其实我写这篇文章的原因，也和你说的一样，我们好多时候写的代码看起来就是感觉是为了分层而分层，所以我们讨论，业务逻辑层应该怎么去做来避免这样的事情。我也说过，对于简单的增删改查来说，的确不能摆脱业务层是一个转发器的现实，那我们就要考虑怎样设计，让我们不再过度的处理这个，而是有没有统一的方式来处理，各位也可以各抒己见，此文算是抛砖引玉。

6 楼 sky726 2009-05-17  

是很有道理，但小弟对这篇文章有几个疑问
表现层、业务逻辑层、数据操作层  各司其职是没错，
但以本篇文章的观点，这是不是太硬性了？
怎么让我感觉是为了分层而分层呢？
您在文章中也说了“简单的系统，可以选择较少的层，反而可以开发效率和系统运行的效率。”
那么，为了实际需要、或提高效率而让某一层做了本不该是这一层做的事，是不是也可以谅解呢

用本文的一个例子，service 中这样写到:
public A saveA(A a){
       return this.aDAO.saveA(a);
}
public List<A> getAs(String a,String b){
       return this.aDAO.getAs(a,b);
}
……

但是就拿分页来说，像我一般的做法就是在dao那写一个执行分页的sql语句(或存储过程)的方法,service调用dao,传几个参数，OK。于是就产生了类似上面的这些代码。

其实很多时候我们也不想这样写的，按照LZ的说法，dao把所有的数据查询出来，再在service层那处理分页，当数据量很大时，那请问效率是不是比我的做法低很多呢???
相信很多人也有这样想过吧。

看语气感觉LZ对分层很执着呢，不过没什么特殊原因业务却又写在dao里边的，相信也大有人在，不然LZ也就不会写这篇文章了，纯属个人观点，本人经验尚浅，就分页这个问题，如果有什么方法即能不违背分层的目的，又能比我那样的代码效率的，还请赐教。

5 楼 lucane 2009-05-16  

我觉得现在的分层基本很乱

service很多时候没有起到应有的作用

DAO基本重复，代码类似，是否能弄个CommonDAO

应当加个facade层，因为现在有了ajax，它需要的数据结构和普通的action根本不同
或者把数据结构的转换都放在action中完成？
希望大牛们给个意见啊

4 楼 lgcpeter 2009-05-15  

service层还是得有的，dao层倒可以简化，action层主要是做页面响应转发用。

3 楼 yanhua 2009-05-15  

楼主说的很有道理。如果能把一些与外部资源无关的领域逻辑再委托给领域模型就更好了。服务层如果能保持轻薄就保持轻薄。

2 楼 mumianiishiwo 2009-05-15  

很有道理，在我参与过的几个项目中，Service都是仅仅起了连接作用而已；
但有没有例子啊？具体怎么让Service发挥更大的作用呢？

1 楼 liangcoder 2009-05-14  

恩，很有道理，领域建模驱动开发才是最重要的。

也许众多持久层框架的产生就是基于把开发人员从持久化的繁琐中解放出来。

支持此文。

但现实情况是，熟悉程序设计语言和相关技术规范的人很多，但熟悉或者掌握面向对象思想

和领域建模的人很少，后者的价值更多的体现在设计领域。