MVC是web開發中常見的程式結構。

簡單的mvc結構如下：

view層：顯示層。 

control層：業務層，集合了各種action。 

model層：模型層，一般和資料打交道。簡單的sample：一個表對應一個model類。

其中control層呼叫model層的方法，實現對資料的訪問。 

採用這樣的結構在一定程度上，可以做到程式碼清晰，較容易擴充套件，程式碼的管理複雜度較低。

但是如果是業務很多，邏輯又很複雜的網站，如果再加上開發人員的水平參差不齊，那必然會導致下面的情況：

1action中的程式碼越來越長，邏輯越來越複雜，不同action之間看起來有很多可以重用的程式碼， 但是真要進行重構的話，又非常困難。

2model層中包含的方法越來越多，有些方法也過於複雜。甚至在不少方法中還包含了業務邏輯。

3程式碼的修改，還是牽一髮而動全身。

4程式碼難以進行自動化測試。

本來以為引入了mvc，程式的管理複雜度問題就高枕無憂了，但現在又面臨了相同的問題了。

以我最近的所學看，在mvc中再引入service層，可以在很大程度上避免或者緩解上述問題。

原有的mvc結構改成如下：

1view層：顯示層。 

2control層：業務層，集合了各種action。 

3service層。

4DAO層。

原來的model層不見了，增加了service層和DAO層。DAO，即Data Access Object，資料訪問介面，資料訪問：顧名思義就是與資料庫打交道

在這個結構中，control不直接和DAO聯絡，

需要操作資料的時候，通過service層訪問DAO層來實現。

service層做的事情，不僅僅是呼叫DAO操作資料，還會包含了一定的業務邏輯。整個程式的設計，也變成了針對服務進行設計。

這樣做的好處是：

1control層中的action得以精簡，因為action中的一些邏輯，被重構成一個個的服務。而不同的action也可以重用服務了。

2只負責和資料打交道的DAO層，相比之前的model層，也得以精簡（DAO層儘量只做最原子的資料操作，不同資料操作之間的聯絡，這邊不考慮，那是service層的事情）。 

3service層可以實現很大程度上的程式碼複用，程式的功能封裝更清晰了。

4由於service層更加清晰的定義了應用程式的邊界，那麼對於各個service函式（對應某個服務/應用），要做到自動化測試就方便多了。WEB程式如何做到能方便的進行單元測試，這是一直困擾我的難題，這樣的設計似乎真的可行了~ 

5開發人員的工作分配，理論上真的可以按層次劃分了。只是理論上~

同時，這樣的設計模式也是存在一定的缺點的：

層次太多，剛接觸的開發人員理解起來比簡單的mvc結構費時；

service層的設計需要一定的功力，因為action中和model層的邏輯在很大程度上轉移到這裡了。

但整體上看，service Layer的引入，更加清晰的定義了應用程式的邊界，提供了一系列可以重用的操作集合。這對於網站的可擴充套件性和可維護性是非常有幫助的。

當然，如果網站的業務邏輯並不複雜，完全沒必要用這樣的設計。過度設計是萬惡之源~