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

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

view層：顯示層,。 

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

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

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

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

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

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

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

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

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

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

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

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

1 view層：顯示層。 

2 control層：業(yè)務(wù)層,，集合了各種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è)務(wù)邏輯,。整個程序的設(shè)計,，也變成了針對服務(wù)進行設(shè)計。

這樣做的好處是：

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

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

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

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

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

同時,，這樣的設(shè)計模式也是存在一定的缺點的：

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

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

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

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