转载：谈J2EE架构分层：业务逻辑层不是转发器
此文乃好文，转之。
原文：http://www.cnblogs.com/xiaoluojava/archive/2010/05/07/1729992.html
我们今天来谈谈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);}……public void saveA(A a){ //保存前某业务逻辑的验证，如数据合法性检查，业务规则验证 this.aDAO.saveA(a); //保存完想JMS发送消息，通知用户已经处理}