在通用的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
转载请保留！