Service层讲解之一

    在刚开始学习Spring时曾被Service绕晕，设计Service时候为什么须要先写一个接口，而后再去实现？Service之间是否能够相互调用？

Service是怎么来的？

Spring MVC，是一个框架，简单说一下，M为模型层，处理数据逻辑，V为视图层，负责展现，而C为控制层，负责M与V的交互。 
在咱们学习的MVC模式，最简单的javabean+jsp+serlvet构成MVC模式，Servlet中的逻辑必定要少，逻辑部分应该放在javabean，即模型层处理，可是模型层还肩负着存储数据的任务（其实这个就是Model所负责的数据逻辑，要实现数据逻辑，要有数据，要有处理），而Service就是将处理、业务抽离出来，能够说是服务层，也能够说是业务层。

为何设计Service时候须要先写接口？

一、业务层接口

   public interface CommentsService extends IBaseService<CGameComments, Integer> {

         Long saveComments(CGameComments comments);

   }

二、业务层实现类

@Service
public class CommentsServiceImpl extends BaseService<CGameComments, Integer>
        implements CommentsService {

   @Override
    public Long saveComments(CGameComments comments) {
        //逻辑部分
    }

}

我写Service时大概就是这种感受，但并无想过为何要这样作。要想理解为何要这样写Service，首先要理解，接口的做用是什么。

接口的做用

接口主要用于描述类具备什么功能，而并不给出每一个功能的具体实现。一个类能够实现一个或多个接口，并在须要接口的地方，随时使用实现了相应接口的对象。——《Java核心技术卷一》

举一个例子来解释，数据源的接口DataSource。 
统一的接入是对于数据源的开发者来讲，要实现数据源，就须要去实现DataSource接口，而后实现其方法。对于DBCP、c3p0、Druid数据源来讲，不一样的开发者，实现同一套东西，这就是统一的接入。 
统一的暴露是对于数据源的使用者来讲。对于数据源的使用者，使用时所要关注的是如何获取数据库链接的动做，即getConnection方法，至于这个动做的具体实现，不须要知道也不关心。 
统一的接入与统一暴露，将实现与使用分离开来，也就是接口所带来的好处。 

去除接口，让Service成为业务

将接口去除，实际上是将Service层，从服务改变为业务，即专一于业务，Service中的都是业务逻辑。有何区别呢？简单点来讲，不用考虑向外提供服务，只为本身系统的业务功能提供服务。 
对于一个中小项目来讲，脱掉Service层接口的枷锁，实现起业务来，十分流畅，再也不用抽象，只关注于业务便可。 
知其然知其因此然，只有清楚为什么写Service时须要先写接口，才能明白为什么要去除接口

Service的互相调用

如今能够明确的说，Service层不该该相互调用，让Service彻底成为一个业务体的设计下，更加不该该相互调用Service。 
有人会问：一个Service的实现的业务，确实能够在另外一个Service中用到，难道要从新写？要清楚，这个状况是出于Service间有通用的逻辑，而不是通用的业务，每一个Service对应一个业务，业务之间应该有明确的分界，否则会出现业务间的耦合，这是设计的不合理。 
既然是Service间的逻辑通用，咱们大可建立一个ServiceHelper类，里面放的，就是Service间的通用逻辑，各自调用这个逻辑便可。固然若是系统庞大起来，这种状况会常常出现，这时再抽象一层，能够叫provider层，提供操做逻辑，例如发短信功能，provider里放的是如何发短信的操做逻辑，而Service层放的是何时发短信，发多少，发给谁的业务逻辑。

业务逻辑只由Service本身知道

Controller必定要尽可能少的逻辑，其实反过来讲，是指Service的逻辑应该高内聚，这样Controller如Service的耦合天然就是最低，Controller真真正正的作到，不用理会Service的实现，只须要调用便可

貌似，如今不少逻辑仍是在Controller