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

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

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

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

在 J2EE架构分层体系中，我一直在思考，谁才是核心，哪一层才是系统最关注的部分。当然大家都很明白，业务才是系统核心，一切随业务的变化而改变。但是在实际的开发中，我却看到很多这样的现象，包括发生在自己身上的。我们过多的关注了表现层和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从中解放出来，让我们更多的关注真实的业务操作，这是下次要思考和讨论的问题。