MVC是web開發中常見的程序結構。
簡單的mvc結構如下：
view層：顯示層。
control層：業務層，集合了各種action。
model層：模型層，一般和數據打交道。簡單的sample：一個表對應一個model類。
其中control層調用model層的方法，實現對數據的訪問。
采用這樣的結構在一定程度上，可以做到代碼清晰，較容易擴展，代碼的管理復雜度較低。
但是如果是業務很多，邏輯又很復雜的網站，如果再加上開發人員的水平參差不齊，那必然會導致下面的情況：
1 action中的代碼越來越長，邏輯越來越復雜，不同action之間看起來有很多可以重用的代碼， 但是真要進行重構的話，又非常困難。
2 model層中包含的方法越來越多，有些方法也過于復雜。甚至在不少方法中還包含了業務邏輯。
3 代碼的修改，還是牽一發而動全身。
4 代碼難以進行自動化測試。
本來以為引入了mvc，程序的管理復雜度問題就高枕無憂了，但現在又面臨了相同的問題了。
以我最近的所學看，在mvc中再引入service層，可以在很大程度上避免或者緩解上述問題。
原有的mvc結構改成如下：
1 view層：顯示層。
2 control層：業務層，集合了各種action。
3 service層。
4 DAO層。
原來的model層不見了，增加了service層和DAO層。DAO，即Data Access Object，數據訪問接口，數據訪問：顧名思義就是與數據庫打交道。
在這個結構中，control不直接和DAO聯系，
需要操作數據的時候，通過service層訪問DAO層來實現。
service層做的事情，不僅僅是調用DAO操作數據，還會包含了一定的業務邏輯。整個程序的設計，也變成了針對服務進行設計。
這樣做的好處是：
1 control層中的action得以精簡，因為action中的一些邏輯，被重構成一個個的服務。而不同的action也可以重用服務了。
2 只負責和數據打交道的DAO層，相比之前的model層，也得以精簡（DAO層盡量只做最原子的數據操作，不同數據操作之間的聯系，這邊不考慮，那是service層的事情）。
3 service層可以實現很大程度上的代碼復用，程序的功能封裝更清晰了。
4 由于service層更加清晰的定義了應用程序的邊界，那么對于各個service函數（對應某個服務/應用），要做到自動化測試就方便多了。WEB程序如何做到能方便的進行單元測試，這是一直困擾我的難題，這樣的設計似乎真的可行了~
5 開發人員的工作分配，理論上真的可以按層次劃分了。只是理論上~
同時，這樣的設計模式也是存在一定的缺點的：
層次太多，剛接觸的開發人員理解起來比簡單的mvc結構費時；
service層的設計需要一定的功力，因為action中和model層的邏輯在很大程度上轉移到這里了。
但整體上看，service Layer的引入，更加清晰的定義了應用程序的邊界，提供了一系列可以重用的操作集合。這對于網站的可擴展性和可維護性是非常有幫助的。
當然，如果網站的業務邏輯并不復雜，完全沒必要用這樣的設計。過度設計是萬惡之源~