Service层在分层中的作用

在通用的J2EE应用分层结构中,经常发现有一个叫Service的分层,那么这个Service层到底是用来做什么的呢 ?简单地就字面理解来说, Service,即服务,那我们可以叫它为服务层。既然作为服务层,那么它的职责理应是为其他层提供服务。Service层应该提供一些什么样的服务呢 ?

事实上,在MVC架构中,Service层是处于比较尴尬的一层。因为你不能说它是属于Model层,也不能说它是属于Controller层,严格来说,它包含了Model层和Controller层这两者的部分职能。为此,我们在开发不同规模以及不同类型的应用时,有时候你会觉得Service层更多地偏向Controller层,而在另一个项目中它却又好像是偏向Model层。那么在实际的项目中,我们该如何来把握Service层更偏向于哪一层。下面我就两种做法作一下简要介绍。

一,首先,谈谈更倾向于Controller层的做法。在这种情况中,Service层事实上应该是要包含大部分Business Logic(业务逻辑)的,而这些逻辑则是通过接口的方式提供给Action层(即Controller)层来调用。 在Action层中,只需要简单地调用Service层所提供的服务即可实现绝大部分逻辑,然后再通过VO(View Object)将数据传递给View层。甚至通过Service层拿数据后的组装工作也可以放到Service中去做,这样做的好处是调用者仅仅只需要通过调用相应Service层的接口即可实现完整的一整套的服务(不需要了解数据是如何组装的),有点类似网站向外界提供API那样。此外,这样做的另一个优点是,当View发生改变时(如表现层技术从Struts到JSF技术的变更时),新的Constroller层只需要一层简单地getter和setter方法的调用,而无需去理会如何进行数据的组装。以为是Service层倾向于Controller层的一种做法,据我所知目前很大部分的公司是采用这种分层作法的。

二,Service层倾向于Model层的做法。在这类分层体系结构中,Service层给人的一种感觉是它是在提供一些基础性的数据服务。换句话说,它只是把Model层原有的数据服务再进行了一定的组装(仅少量涉及业务逻辑),之后作为接口提供给Controller层调用。所以,实际上负责主要数据组装工作(Business Logic,业务逻辑)的是在Controller层,它不过是调用了Service层提供的一些较为基础性的数据服务。那么, 这种做法相比第一种会有什么好处呢 ?其实,它带来的好处主要体现在分层架构上更加清晰,每一层都剥离得比较干净。从另一个角度来讲,Model层、Service层、Controller层我们都可以较容易地进行剥离,大大地增加了灵活性。

以上为个人的一些观点,如有不足之处,请不吝指正。


原文出处:http://blog.csdn.net/oathevil/article/details/7288566

转载请保留!

你可能感兴趣的:(Java)