現(xiàn)在開(kāi)發(fā)應(yīng)用程序經(jīng)常使用一些所見(jiàn)即所得的開(kāi)發(fā)環(huán)境，使得用戶界面的制作非常方便。然而，用戶界面是最容易發(fā)生需求變更的部分，用戶界面發(fā)生變化，經(jīng)常對(duì)業(yè)務(wù)模塊產(chǎn)生影響。并且，用戶界面是不利于自動(dòng)測(cè)試的。一旦某些代碼依賴用戶界面，這樣的代碼就很難在別的模塊中調(diào)用了，因此業(yè)務(wù)邏輯不能在界面層次中進(jìn)行，否則會(huì)造成不能復(fù)用，不能復(fù)用自然會(huì)增加復(fù)制粘貼的代碼，造成錯(cuò)誤的擴(kuò)散，放大需求變更的影響。在程序設(shè)計(jì)中，應(yīng)該盡量做到用戶界面和底層的業(yè)務(wù)模型分離。
用戶界面和業(yè)務(wù)模塊的互動(dòng)方式，在程序設(shè)計(jì)中經(jīng)常采用MVC模式。MVC模式并不是一個(gè)特別的模式，而是一些特定模式的組合?；旧习ㄈ齻€(gè)對(duì)象：業(yè)務(wù)模塊（Model）、用戶界面（View）和控制器（Controller），關(guān)系如下：
圖中實(shí)線表示高耦合的依賴關(guān)系，虛線表示低耦合的消息關(guān)系。業(yè)務(wù)模塊是不依賴用戶界面的，這樣就隔離了用戶界面的變更對(duì)業(yè)務(wù)程序的影響。用戶界面負(fù)責(zé)收集用戶的輸入，顯示用戶需要的數(shù)據(jù)；控制器負(fù)責(zé)將用戶的請(qǐng)求調(diào)用到實(shí)際的業(yè)務(wù)程序，也將業(yè)務(wù)程序處理的結(jié)果回送給用戶界面；業(yè)務(wù)程序具體處理業(yè)務(wù)操作。同時(shí)業(yè)務(wù)模塊可能主動(dòng)發(fā)送消息到用戶界面，通知界面顯示數(shù)據(jù)。
在具體的環(huán)境下，這些因素可能發(fā)生一些變化。比如，在web開(kāi)發(fā)中，由于web應(yīng)用程序的性質(zhì)，用戶界面是在瀏覽器上運(yùn)行的，而界面的控制和業(yè)務(wù)模塊在瀏覽器上運(yùn)行，所以在web應(yīng)用中通常采用這種典型的MVC模式。并且在Web應(yīng)用中，不存在服務(wù)器主動(dòng)向客戶端“推”數(shù)據(jù)，因此從Model到View之間的虛線也是不存在的。在windows窗體程序中，控制器和界面經(jīng)常是合并在一起的，比如MFC框架中使用的Document－View模式，其中的Document對(duì)應(yīng)MVC中的Model，負(fù)責(zé)保存業(yè)務(wù)數(shù)據(jù)，處理業(yè)務(wù)邏輯，View相當(dāng)于MVC中的View＋Controller，負(fù)責(zé)用戶界面的顯示、用戶輸入的收集和畫(huà)面的跳轉(zhuǎn)控制。
好的設(shè)計(jì)和壞的設(shè)計(jì)有時(shí)候需要寫(xiě)的代碼是一樣多的，但是這些代碼放的位置不一樣。MVC中最重要的一點(diǎn)就是清楚Controller應(yīng)該處于什么樣的地位，應(yīng)該完成什么樣的功能。下面用一個(gè)web應(yīng)用程序的例子來(lái)說(shuō)明一下。
Jsp編程有一些MVC的框架，比如Struts，Struts控制器的工作如下：首先是一個(gè)請(qǐng)求分派機(jī)制，負(fù)責(zé)監(jiān)聽(tīng)請(qǐng)求和分配請(qǐng)求，然后是一個(gè)Command模式的實(shí)現(xiàn)，負(fù)責(zé)處理請(qǐng)求。首先收到服務(wù)器收到客戶端的http請(qǐng)求，交給控制器分析其中的地址，在一個(gè)配置文件中尋找對(duì)應(yīng)的處理者（一個(gè)Action的子類(lèi)），建立這個(gè)類(lèi)的實(shí)例，隨后執(zhí)行其execute方法，Action類(lèi)中調(diào)用業(yè)務(wù)模塊進(jìn)行實(shí)際業(yè)務(wù)的處理（在處理之前進(jìn)行必要的準(zhǔn)備，比如分析請(qǐng)求的參數(shù)，將其轉(zhuǎn)化為業(yè)務(wù)模型了解的對(duì)象），得到處理結(jié)果，根據(jù)處理的結(jié)果決定需要顯示的View。這個(gè)需要顯示的View在Struts框架中也是在文件中配置的。
這是一種集中式的控制器，應(yīng)用程序使用一個(gè)統(tǒng)一的Controller。不僅使業(yè)務(wù)和界面分離開(kāi)，并且界面的流程完全由同一個(gè)對(duì)象來(lái)控制。最重要的是，使得功能的修改和追加變得比較方便，控制器成為業(yè)務(wù)模塊的緩沖，減輕了需求變化對(duì)業(yè)務(wù)模塊的影響。
很多windows窗體程序也采用這樣的控制器。有一個(gè)開(kāi)放源碼的.Net開(kāi)發(fā)工具，叫做SharpDev，本身也是用c#開(kāi)發(fā)的，采用的就是這樣的集中控制方式。SharpDev是用add-in的方式進(jìn)行增量開(kāi)發(fā)的，程序中的功能，如打開(kāi)文件、保存文件、運(yùn)行某個(gè)向?qū)У裙δ芏际且粋€(gè)個(gè)獨(dú)立的add-in，使用了Command模式。程序運(yùn)行過(guò)程大致如下：應(yīng)用程序初始化的時(shí)候，讀取配置文件中所有名稱(chēng)為*.add-in的文件，得到程序中所有的add-in，可以把這些add-in看作一個(gè)ICommand接口的實(shí)現(xiàn)。根據(jù)配置文件建立這些ICommand的實(shí)例，綁定在對(duì)應(yīng)的菜單項(xiàng)和工具欄按鈕上。當(dāng)用戶點(diǎn)擊這些菜單項(xiàng)和工具欄按鈕的時(shí)候，由一個(gè)任務(wù)分派的對(duì)象將請(qǐng)求定位到一個(gè)Command上，執(zhí)行其Run方法。Command執(zhí)行的時(shí)候可能要調(diào)用業(yè)務(wù)程序，業(yè)務(wù)程序是通過(guò)一系列的Service對(duì)外提供功能的，不直接向外界暴露。Controller就是負(fù)責(zé)定向用戶操作到具體Command的分派器。
窗體應(yīng)用程序還有一個(gè)特點(diǎn)：有時(shí)候業(yè)務(wù)改變的時(shí)候，需要用戶界面作出相應(yīng)的變化。比如：當(dāng)代碼編輯器中的文字發(fā)生變更的時(shí)候，工具欄上的保存按鈕要置為可用狀態(tài)，當(dāng)保存后，保存按鈕又要置為灰色。這樣的功能是通過(guò)一個(gè)Observeor模式來(lái)實(shí)現(xiàn)的，這就避免了業(yè)務(wù)模塊對(duì)用戶界面的依賴，并且這樣的模式也便于同時(shí)將消息發(fā)送給多個(gè)對(duì)象，比如保存按鈕不僅要在工具欄上出現(xiàn)，也要在菜單上出現(xiàn)，這樣的變化是不會(huì)影響業(yè)務(wù)模塊的。在SharpDev中，這個(gè)交互的過(guò)程也是在業(yè)務(wù)模塊對(duì)外提供的Service中通過(guò)delegate來(lái)實(shí)現(xiàn)的。
很多應(yīng)用程序采用的是另一種控制模式：每個(gè)畫(huà)面和窗口使用自己的控制器。在窗體程序中，這樣的方式實(shí)際上就將用戶界面和控制器融合在一起了，比如MFC中的Document－View，View不僅實(shí)現(xiàn)用戶數(shù)據(jù)的展示和輸入數(shù)據(jù)的收集，還要將用戶的輸入進(jìn)行基本的處理，轉(zhuǎn)變?yōu)闃I(yè)務(wù)模塊了解的類(lèi)型，調(diào)用業(yè)務(wù)模塊進(jìn)行處理，最后跳轉(zhuǎn)到別的窗口。
在ASP.NET中使用code behide的編程框架，實(shí)際上也是為每一個(gè)用戶界面采用了一個(gè)獨(dú)立的Controller，aspx文件就是用戶界面，對(duì)應(yīng)的code behide代碼就是他的控制器。這樣的框架減少了程序的靈活性，但是在一般情況下可以使應(yīng)用程序的框架變得簡(jiǎn)單和直接。聯(lián)系客服
