以我之前的iOS所經(jīng)歷，一般項(xiàng)目中用到的MVC設(shè)計(jì)模式（MVVM）

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

1view層：顯示層。

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

3service層。

4DAO層。

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

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

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

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

這樣做的好處是：

1control層中的action得以精簡(jiǎn)，因?yàn)閍ction中的一些邏輯，被重構(gòu)成一個(gè)個(gè)的服務(wù)。而不同的action也可以重用服務(wù)了。

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

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

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

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

同時(shí)，這樣的設(shè)計(jì)模式也是存在一定的缺點(diǎn)的：

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

service層的設(shè)計(jì)需要一定的功力，因?yàn)閍ction中和model層的邏輯在很大程度上轉(zhuǎn)移到這里了。

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

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