MVC是web開發(fā)中常見的程序結(jié)構(gòu)。

簡單的mvc結(jié)構(gòu)如下：

view層：顯示層。 

control層：業(yè)務層，集合了各種action。 

model層：模型層，一般和數(shù)據(jù)打交道。簡單的sample：一個表對應一個model類。

其中control層調(diào)用model層的方法，實現(xiàn)對數(shù)據(jù)的訪問。 

采用這樣的結(jié)構(gòu)在一定程度上，可以做到代碼清晰，較容易擴展，代碼的管理復雜度較低。

但是如果是業(yè)務很多，邏輯又很復雜的網(wǎng)站，如果再加上開發(fā)人員的水平參差不齊，那必然會導致下面的情況：

1 action中的代碼越來越長，邏輯越來越復雜，不同action之間看起來有很多可以重用的代碼， 但是真要進行重構(gòu)的話，又非常困難。

2 model層中包含的方法越來越多，有些方法也過于復雜。甚至在不少方法中還包含了業(yè)務邏輯。

3 代碼的修改，還是牽一發(fā)而動全身。

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

本來以為引入了mvc，程序的管理復雜度問題就高枕無憂了，但現(xiàn)在又面臨了相同的問題了。

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

原有的mvc結(jié)構(gòu)改成如下：

1 view層：顯示層。 

2 control層：業(yè)務層，集合了各種action。 

3 service層。

4 DAO層。

原來的model層不見了，增加了service層和DAO層。DAO，即Data Access Object，數(shù)據(jù)訪問接口，數(shù)據(jù)訪問：顧名思義就是與數(shù)據(jù)庫打交道。

在這個結(jié)構(gòu)中，control不直接和DAO聯(lián)系，

需要操作數(shù)據(jù)的時候，通過service層訪問DAO層來實現(xiàn)。

service層做的事情，不僅僅是調(diào)用DAO操作數(shù)據(jù)，還會包含了一定的業(yè)務邏輯。整個程序的設計，也變成了針對服務進行設計。

這樣做的好處是：

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

2 只負責和數(shù)據(jù)打交道的DAO層，相比之前的model層，也得以精簡（DAO層盡量只做最原子的數(shù)據(jù)操作，不同數(shù)據(jù)操作之間的聯(lián)系，這邊不考慮，那是service層的事情）。 

3 service層可以實現(xiàn)很大程度上的代碼復用，程序的功能封裝更清晰了。

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

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

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

層次太多，剛接觸的開發(fā)人員理解起來比簡單的mvc結(jié)構(gòu)費時；

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

但整體上看，service Layer的引入，更加清晰的定義了應用程序的邊界，提供了一系列可以重用的操作集合。這對于網(wǎng)站的可擴展性和可維護性是非常有幫助的。

當然，如果網(wǎng)站的業(yè)務邏輯并不復雜，完全沒必要用這樣的設計。過度設計是萬惡之源~