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