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

在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