谭明智的空间

我们一直在努力....

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

标签: 架构分层 J2EE架构分层 j2ee mvc dao

我们今天来谈谈J2EE架构分层---yongtree想谈的是业务逻辑层不是转发器。

在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从中解放出来,让我们更多的关注真实的业务操作,这是下次要思考和讨论的问题。

    评分: 请先登录再投票,同一篇博客一月只能投票一次!
    无人投票

相关博客:


评论


发表评论

关注此文的人们还关注