以我之前的iOS所經歷，一般項目中用到的MVC設計模式（MVVM）
原有的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層的邏輯在很大程度上轉移到這里了。
但整體上看，serviceLayer的引入，更加清晰的定義了應用程序的邊界，提供了一系列可以重用的操作集合。這對于網站的可擴展性和可維護性是非常有幫助的。
當然，如果網站的業務邏輯并不復雜，完全沒必要用這樣的設計。過度設計是萬惡之源~
