一、什么是模式？什么是框架？

1、什么是模式？

模式，即pattern。其實(shí)就是解決某一類問(wèn)題的方法論。你把解決某類問(wèn)題的方法總結(jié)歸納到理論高度，那就是模式。

Alexander給出的經(jīng)典定義是：每個(gè)模式都描述了一個(gè)在我們的環(huán)境中不斷出現(xiàn)的問(wèn)題，然后描述了該問(wèn)題的解決方案的核心。通過(guò)這種方式，你可以無(wú)數(shù)次地使用那些已有的解決方案，無(wú)需在重復(fù)相同的工作。

模式有不同的領(lǐng)域，建筑領(lǐng)域有建筑模式，軟件設(shè)計(jì)領(lǐng)域也有設(shè)計(jì)模式。當(dāng)一個(gè)領(lǐng)域逐漸成熟的時(shí)候，自然會(huì)出現(xiàn)很多模式。

2、什么是框架？

框架，即framework。其實(shí)就是某種應(yīng)用的半成品，就是一組組件，供你選用完成你自己的系統(tǒng)。簡(jiǎn)單說(shuō)就是使用別人搭好的舞臺(tái)，你來(lái)做表演。而且，框架一般是成熟的，不斷升級(jí)的軟件。

3、為什么要用模式？

因?yàn)槟Ｊ绞且环N指導(dǎo)，在一個(gè)良好的指導(dǎo)下，有助于你完成任務(wù)，有助于你作出一個(gè)優(yōu)良的設(shè)計(jì)方案，達(dá)到事半功倍的效果。而且會(huì)得到解決問(wèn)題的最佳辦法。

為什么要用框架？

因?yàn)檐浖到y(tǒng)發(fā)展到今天已經(jīng)很復(fù)雜了，特別是服務(wù)器端軟件，設(shè)計(jì)到的知識(shí)，內(nèi)容，問(wèn)題太多。在某些方面使用別人成熟的框架，就相當(dāng)于讓別人幫你完成一些基礎(chǔ)工作，你只需要集中精力完成系統(tǒng)的業(yè)務(wù)邏輯設(shè)計(jì)。而且框架一般是成熟，穩(wěn)健的，他可以處理系統(tǒng)很多細(xì)節(jié)問(wèn)題，比如，事物處理，安全性，數(shù)據(jù)流控制等問(wèn)題。還有框架一般都經(jīng)過(guò)很多人使用，所以結(jié)構(gòu)很好，所以擴(kuò)展性也很好，而且它是不斷升級(jí)的，你可以直接享受別人升級(jí)代碼帶來(lái)的好處。

框架一般處在低層應(yīng)用平臺(tái)（如J2EE）和高層業(yè)務(wù)邏輯之間的中間層。

軟件為什么要分層？

為了實(shí)現(xiàn)“高內(nèi)聚、低耦合”。把問(wèn)題劃分開(kāi)來(lái)各個(gè)解決，易于控制，易于延展，易于分配資源…總之好處很多啦

二、MVC架構(gòu)開(kāi)發(fā)

MVC是一種軟件開(kāi)發(fā)架構(gòu)，它包含了很多的設(shè)計(jì)模式，最為密切的有以下3種：Observer（觀察者模式）、Composite（合成模式）和Strategy（策略模式）。本節(jié)主要論述MVC架構(gòu)的原理、優(yōu)缺點(diǎn)以及MVC為Web應(yīng)用程序帶來(lái)的好處。

1、什么是MVC架構(gòu)

模型（Model）－視圖（View）－控制器（Controller）即為MVC，MVC在八十年代為編程語(yǔ)言Smalltalk－80發(fā)明的一種軟件架構(gòu)模式，至今已被廣泛使用。模型－視圖－控制器模式是一個(gè)有用的工具箱，但它也存在一些不足。

2、MVC工作原理

MVC是一個(gè)設(shè)計(jì)模式，它使應(yīng)用程序的輸入、處理和輸出強(qiáng)制性分開(kāi)，使得軟件可維護(hù)性、可擴(kuò)展性、靈活性以及封裝性得到提高。使用MVC應(yīng)用程序被分成三個(gè)核心部件：M（模型）、V（視圖）、C（控制器）。模型是所有的商業(yè)邏輯代碼片段所在。視圖表示數(shù)據(jù)在屏幕上的顯示。控制器提供處理過(guò)程控制，它在模型和視圖之間起連接作用?？刂破鞅旧聿惠敵鋈魏涡畔⒑妥鋈魏翁幚恚回?fù)責(zé)把用戶的請(qǐng)求轉(zhuǎn)成針對(duì)Model的操作，和調(diào)用相應(yīng)的視圖來(lái)顯示Model處理后的數(shù)據(jù)。三者之間關(guān)系。

MVC（Model-View-Controller）把系統(tǒng)的組成分解為M（模型）、V（視圖）、C（控制器）三種部件。下面分別對(duì)這三個(gè)核心部件進(jìn)行介紹。

模型

模型表示企業(yè)數(shù)據(jù)和業(yè)務(wù)規(guī)則。在MVC的三個(gè)部件中，模型擁有最多的處理任務(wù)。被模型返回的數(shù)據(jù)是中立的，就是說(shuō)模型與數(shù)據(jù)格式無(wú)關(guān)，這樣一個(gè)模型能為多個(gè)視圖提供數(shù)據(jù)。由于應(yīng)用于模型的代碼只需寫(xiě)一次就可以被多個(gè)視圖重用，所以減少了代碼的重復(fù)性。

視圖

視圖是用戶可以看到并與之交互的界面。視圖就是由HTML元素組成的界面，HTML依舊在視圖中扮演著重要的角色，但一些新的技術(shù)已層出不窮，它們包括MacromediaFlash、XHTML、XML/XSL、WML等一些標(biāo)識(shí)語(yǔ)言和WebServices等。

如何處理應(yīng)用程序的界面變得越來(lái)越有挑戰(zhàn)性。MVC有一個(gè)突出的優(yōu)點(diǎn)是能為應(yīng)用程序處理很多不同的視圖，在視圖中其實(shí)沒(méi)有真正的處理發(fā)生，不管這些數(shù)據(jù)是聯(lián)機(jī)存儲(chǔ)的還是本地儲(chǔ)存，作為視圖來(lái)講，它只是作為一種輸出數(shù)據(jù)并允許用戶操縱的方式。

控制器

現(xiàn)在總結(jié)ＭVC的處理過(guò)程，首先控制器接收用戶的請(qǐng)求，并決定應(yīng)該調(diào)用哪個(gè)模型來(lái)進(jìn)行處理，然后模型用業(yè)務(wù)邏輯來(lái)處理用戶的請(qǐng)求并返回?cái)?shù)據(jù)，最后控制器用相應(yīng)的視圖格式化模型返回的數(shù)據(jù)，并通過(guò)表示層呈現(xiàn)給用戶。

三、為什么要使用MVC架構(gòu)

ASP.NET提供了一個(gè)很好的實(shí)現(xiàn)這種經(jīng)典設(shè)計(jì)模式的環(huán)境。程序人員通過(guò)在ASPX頁(yè)面中開(kāi)發(fā)用戶接口來(lái)實(shí)現(xiàn)視圖，控制器的功能在邏輯功能代碼（.cs）中實(shí)現(xiàn)，模型通常對(duì)應(yīng)系統(tǒng)的業(yè)務(wù)部分。在ASP.NET中實(shí)現(xiàn)這種設(shè)計(jì)而提供的一個(gè)多層系統(tǒng)，將數(shù)據(jù)（模型）從對(duì)其操作的動(dòng)作（控制器）分離出來(lái)可以設(shè)計(jì)一個(gè)與后臺(tái)存儲(chǔ)數(shù)據(jù)無(wú)關(guān)的系統(tǒng)，就MVC結(jié)構(gòu)的本質(zhì)而言，它是一種解決耦合系統(tǒng)問(wèn)題的方法。

在ASP.NET中編寫(xiě)MVC模式具有極其良好的可擴(kuò)展性。它可以輕松實(shí)現(xiàn)以下功能：

實(shí)現(xiàn)一個(gè)模型的多個(gè)視圖

采用多個(gè)控制器

當(dāng)模型改變時(shí)，所有視圖將自動(dòng)刷新

所有的控制器將相互獨(dú)立工作

這就是MVC架構(gòu)的好處，只需在以前的程序上稍作修改或增加新的類，即可增添程序的功能。以前開(kāi)發(fā)的類可以重用，而程序結(jié)構(gòu)根本不再需要改變，各類之間相互獨(dú)立，便于團(tuán)體開(kāi)發(fā)，提高開(kāi)發(fā)效率。

下面介紹一下使用MVC架構(gòu)的優(yōu)點(diǎn)：

1、提高代碼重用率

最重要的一點(diǎn)是多個(gè)視圖能共享一個(gè)模型，無(wú)論用戶想要Flash界面或是WAP界面；用一個(gè)模型就能處理它們。由于已經(jīng)將數(shù)據(jù)和業(yè)務(wù)規(guī)則從表示層分開(kāi)，所以可以最大化的重用代碼。

2、提高程序的可維護(hù)性

因?yàn)槟Ｐ褪亲园?，并且與控制器和視圖相分離，所以很容易改變數(shù)據(jù)層和業(yè)務(wù)規(guī)則。例如，把數(shù)據(jù)庫(kù)從SQLServer移植到Oracle，只需改變模型即可。一旦正確的實(shí)現(xiàn)了模型，不管數(shù)據(jù)來(lái)自哪里，視圖都會(huì)正確的顯示它們。MVC架構(gòu)的運(yùn)用，使得程序的三個(gè)部件相互對(duì)立，大大提高了程序的可維護(hù)性。

3、有利于團(tuán)隊(duì)開(kāi)發(fā)

在開(kāi)發(fā)過(guò)程中，可以更好地分工，更好地協(xié)作。有利于開(kāi)發(fā)出高質(zhì)量的軟件。良好的項(xiàng)目架構(gòu)設(shè)計(jì)，將減少編碼工作量。采用MVC結(jié)構(gòu)和代碼生成器，是大多數(shù)Web應(yīng)用程序的理想選擇。部分模型（Model）和存儲(chǔ)過(guò)程一般可用工具自動(dòng)生成?？刂破鳎?/span>Controller）比較穩(wěn)定，一般由架構(gòu)師（或經(jīng)驗(yàn)豐富程序人員）完成；那么整個(gè)項(xiàng)目需要手動(dòng)編寫(xiě)代碼的地方就只有視圖(View)了。在這種模式下，個(gè)人能力不是特別重要，只要懂點(diǎn)語(yǔ)法基礎(chǔ)的人都可以編寫(xiě)，無(wú)論項(xiàng)目成員寫(xiě)出什么樣的代碼，都在項(xiàng)目管理者的可控范圍內(nèi)。即使開(kāi)放項(xiàng)目途中人員流動(dòng)，也不會(huì)有太大問(wèn)題。在個(gè)人能力不均衡的團(tuán)隊(duì)開(kāi)發(fā)中，采用MVC開(kāi)發(fā)是非常理想的。

另外，MVC架構(gòu)可以實(shí)現(xiàn)一個(gè)模型、兩個(gè)視圖和一個(gè)控制器的程序。下面將討論如何實(shí)現(xiàn)一個(gè)模型、兩個(gè)視圖和一個(gè)控制器的程序。其中模型類及視圖類根本不需要改變，與前面的完全一樣，這就是面向?qū)ο缶幊痰暮锰?。?duì)于控制器中的類，只需要增加另一個(gè)視圖，并與模型發(fā)生關(guān)聯(lián)即可。

同樣也可以實(shí)現(xiàn)其他形式的MVC。例如：一個(gè)模型、兩個(gè)視圖和兩個(gè)控制器。從上面可以看出，通過(guò)MVC模式實(shí)現(xiàn)的應(yīng)用程序具有極其良好的可擴(kuò)展性，是ASP.NET面向?qū)ο缶幊痰奈磥?lái)方向。

四、表示層——業(yè)務(wù)邏輯層——數(shù)據(jù)訪問(wèn)層

1、什么是三層架構(gòu)

所謂的三層開(kāi)發(fā)就是將系統(tǒng)的整個(gè)業(yè)務(wù)應(yīng)用劃分為表示層——業(yè)務(wù)邏輯層——數(shù)據(jù)訪問(wèn)層，這樣有利于系統(tǒng)的開(kāi)發(fā)、維護(hù)、部署和擴(kuò)展。

分層是為了實(shí)現(xiàn)“高內(nèi)聚、低耦合”。采用“分而治之”的思想，把問(wèn)題劃分開(kāi)來(lái)各個(gè)解決，易于控制，易于延展，易于分配資源。

表示層：負(fù)責(zé)直接跟用戶進(jìn)行交互，一般也就是指系統(tǒng)的界面，用于數(shù)據(jù)錄入，數(shù)據(jù)顯示等。意味著只做與外觀顯示相關(guān)的工作，不屬于他的工作不用做。

業(yè)務(wù)邏輯層：用于做一些有效性驗(yàn)證的工作，以更好地保證程序運(yùn)行的健壯性。如完成數(shù)據(jù)添加、修改和查詢業(yè)務(wù)等；不允許指定的文本框中輸入空字符串，數(shù)據(jù)格式是否正確及數(shù)據(jù)類型驗(yàn)證；用戶的權(quán)限的合法性判斷等等，通過(guò)以上的諸多判斷以決定是否將操作繼續(xù)向后傳遞，盡量保證程序的正常運(yùn)行。

數(shù)據(jù)訪問(wèn)層：顧名思義，就是用于專門(mén)跟數(shù)據(jù)庫(kù)進(jìn)行交互。執(zhí)行數(shù)據(jù)的添加、刪除、修改和顯示等。需要強(qiáng)調(diào)的是，所有的數(shù)據(jù)對(duì)象只在這一層被引用，如System.Data.SqlClient等，除數(shù)據(jù)層之外的任何地方都不應(yīng)該出現(xiàn)這樣的引用。

ASP.NET可以使用.NET平臺(tái)快速方便地部署三層架構(gòu)。ASP.NET革命性的變化是在網(wǎng)頁(yè)中也使用基于事件的處理，可以指定處理的后臺(tái)代碼文件，可以使用C#、VB、C++和J#作為后臺(tái)代碼的語(yǔ)言。.NET中可以方便的實(shí)現(xiàn)組件的裝配，后臺(tái)代碼通過(guò)命名空間可以方便的使用自己定義的組件。顯示層放在ASPX頁(yè)面中，數(shù)據(jù)庫(kù)操作和邏輯層用組件或封裝類來(lái)實(shí)現(xiàn)，這樣就很方便的實(shí)現(xiàn)了三層架構(gòu)。

2、為什么使用三層架構(gòu)

對(duì)于一個(gè)簡(jiǎn)單的應(yīng)用程序來(lái)說(shuō)，代碼量不是很多的情況下，一層結(jié)構(gòu)或二層結(jié)構(gòu)開(kāi)發(fā)完全夠用，沒(méi)有必要將其復(fù)雜化，如果對(duì)一個(gè)復(fù)雜的大型系統(tǒng)，設(shè)計(jì)為一層結(jié)構(gòu)或二層結(jié)構(gòu)開(kāi)發(fā)，那么這樣的設(shè)計(jì)存在很嚴(yán)重缺陷。下面會(huì)具體介紹，分層開(kāi)發(fā)其實(shí)是為大型系統(tǒng)服務(wù)的。

在開(kāi)發(fā)過(guò)程中，初級(jí)程序人員出現(xiàn)相似的功能經(jīng)常復(fù)制代碼，那么同樣的代碼為什么要寫(xiě)那么多次？不但使程序變得冗長(zhǎng)，更不利于維護(hù)，一個(gè)小小的修改或許會(huì)涉及很多頁(yè)面，經(jīng)常導(dǎo)致異常的產(chǎn)生使程序不能正常運(yùn)行。最主要的面向?qū)ο蟮乃枷霙](méi)有得到絲毫的體現(xiàn)，打著面向?qū)ο蟮幕献訁s依然走著面向過(guò)程的道路。

意識(shí)到這樣的問(wèn)題，初級(jí)程序人員開(kāi)始將程序中一些公用的處理程序?qū)懗晒卜椒?，封裝在類中，供其它程序調(diào)用。例如寫(xiě)一個(gè)數(shù)據(jù)操作類，對(duì)數(shù)據(jù)操作進(jìn)行合理封裝，在數(shù)據(jù)庫(kù)操作過(guò)程中，只要類中的相應(yīng)方法（數(shù)據(jù)添加、修改、查詢等）可以完成特定的數(shù)據(jù)操作，這就是數(shù)據(jù)訪問(wèn)層，不用每次操作數(shù)據(jù)庫(kù)時(shí)都寫(xiě)那些重復(fù)性的數(shù)據(jù)庫(kù)操作代碼。在新的應(yīng)用開(kāi)發(fā)中，數(shù)據(jù)訪問(wèn)層可以直接拿來(lái)用。面向?qū)ο蟮娜筇匦灾坏姆庋b性在這里得到了很好的體現(xiàn)。讀者現(xiàn)在似乎找到了面向?qū)ο蟮母杏X(jué)，代碼量較以前有了很大的減少，而且修改的時(shí)候也比較方便，也實(shí)現(xiàn)了代碼的重用性。

下面舉兩個(gè)案例，解釋一下為什么要使用三層架構(gòu)。

案例一：

數(shù)據(jù)庫(kù)系統(tǒng)軟件由于數(shù)據(jù)量的不斷增加，數(shù)據(jù)庫(kù)由Access變成了SQLServer數(shù)據(jù)庫(kù)，這樣原來(lái)的數(shù)據(jù)訪問(wèn)層失效了，數(shù)據(jù)操作對(duì)象發(fā)生了變化，并且頁(yè)面中涉及數(shù)據(jù)對(duì)象的地方也要進(jìn)行修改，因?yàn)樵瓉?lái)可能會(huì)使用OleDbDataReader對(duì)象將數(shù)據(jù)傳遞給顯示頁(yè)面，現(xiàn)在都得換成SqlDataReader對(duì)象，SQLServer和Access支持的數(shù)據(jù)類型也不一致，在顯示數(shù)據(jù)時(shí)進(jìn)行的數(shù)據(jù)轉(zhuǎn)換也要進(jìn)行修改，這是其中一種情況。

案例二：

由于特殊情況需要，把Web形式的項(xiàng)目改造成Windows應(yīng)用，此時(shí)需要做多少修改呢？如果在Aspx.cs中占據(jù)了大量代碼，或者還有部分代碼存在于Aspx中，那么整個(gè)系統(tǒng)是否需要重新來(lái)開(kāi)發(fā)呢？

在上面的案例中是否體會(huì)到了沒(méi)有分層開(kāi)發(fā)模式的缺陷呢？是否碰到過(guò)這樣的情況呢？這都是由設(shè)計(jì)不合理造成的，多層開(kāi)發(fā)架構(gòu)的出現(xiàn)可以很好地解決該問(wèn)題，通過(guò)程序架構(gòu)進(jìn)行合理的分層，將極大地提高程序的通用性。

3、使用三層架構(gòu)開(kāi)發(fā)的優(yōu)點(diǎn)

使用三層架構(gòu)開(kāi)發(fā)有以下優(yōu)點(diǎn)：

從開(kāi)發(fā)角度和應(yīng)用角度來(lái)看，三層架構(gòu)比二層架構(gòu)或單層架構(gòu)都有更大的優(yōu)勢(shì)。三層架構(gòu)適合團(tuán)隊(duì)開(kāi)發(fā)，每人可以有不同的分工，協(xié)同工作使效率倍增。開(kāi)發(fā)二層或單層應(yīng)用程序時(shí)，每個(gè)開(kāi)發(fā)人員都應(yīng)對(duì)系統(tǒng)有較深的理解，能力要求很高，開(kāi)發(fā)三層應(yīng)用程序時(shí)，則可以結(jié)合多方面的人才，只需少數(shù)人對(duì)系統(tǒng)全面了解即可，從一定程度降低了開(kāi)發(fā)的難度。

三層架構(gòu)可以更好的支持分布式計(jì)算環(huán)境。邏輯層的應(yīng)用程序可以在多個(gè)計(jì)算機(jī)上運(yùn)行，充分利用網(wǎng)絡(luò)的計(jì)算功能。分布式計(jì)算的潛力巨大，遠(yuǎn)比升級(jí)CPU有效。美國(guó)人曾利用分式計(jì)算解密，幾個(gè)月就破解了據(jù)稱永遠(yuǎn)都破解不了的密碼。

三層架構(gòu)的最大優(yōu)點(diǎn)是它的安全性。用戶只能通過(guò)邏輯層來(lái)訪問(wèn)數(shù)據(jù)層，減少了入口點(diǎn)，把很多危險(xiǎn)的系統(tǒng)功能都屏蔽了。

4、三層架構(gòu)的種類

目前，團(tuán)隊(duì)開(kāi)發(fā)人員在開(kāi)發(fā)項(xiàng)目時(shí)，大多都使用分層開(kāi)發(fā)架構(gòu)設(shè)計(jì)，最常見(jiàn)的就是三層架構(gòu)，目的在于使各個(gè)層之間只能夠被它相鄰的層產(chǎn)生影響，但是這個(gè)限制常常在使用多層開(kāi)發(fā)的時(shí)候被違反，這對(duì)系統(tǒng)的開(kāi)發(fā)是有害的。三層架構(gòu)按驅(qū)動(dòng)模式可劃分三種：數(shù)據(jù)層驅(qū)動(dòng)模式、陳述層驅(qū)動(dòng)模式和隔離驅(qū)動(dòng)模式，其中隔離驅(qū)動(dòng)模式開(kāi)發(fā)最為重要。下面通過(guò)三種模式的對(duì)比，介紹隔離驅(qū)動(dòng)模式的重要性。

數(shù)據(jù)層驅(qū)動(dòng)模式

所謂的數(shù)據(jù)層驅(qū)動(dòng)模式，就是先設(shè)計(jì)數(shù)據(jù)層，陳述層圍繞數(shù)據(jù)層展開(kāi)，一旦完成了數(shù)據(jù)層和陳述層，業(yè)務(wù)層就圍繞數(shù)據(jù)層展開(kāi)。因?yàn)殛愂鰧邮菄@數(shù)據(jù)層展開(kāi)的，這將會(huì)使陳述層中的約束不準(zhǔn)確，并且限制了業(yè)務(wù)層的變更。由于業(yè)務(wù)層受到限制，一些簡(jiǎn)單變化可以通過(guò)SQL查詢和存儲(chǔ)過(guò)程來(lái)實(shí)現(xiàn)。

這種模式非常的普遍，它和傳統(tǒng)的客戶服務(wù)端開(kāi)發(fā)相似，并且是圍繞已經(jīng)存在的數(shù)據(jù)庫(kù)設(shè)計(jì)的。由于陳述層是圍繞數(shù)據(jù)層設(shè)計(jì)的，它常常是憑直覺(jué)模仿數(shù)據(jù)層的實(shí)際結(jié)構(gòu)。

常常存在一種額外的反饋循環(huán)在陳述層到數(shù)據(jù)之間，當(dāng)在設(shè)計(jì)陳述層不容易實(shí)現(xiàn)的時(shí)候常常會(huì)去修改數(shù)據(jù)層，也就形成了這種反饋循環(huán)。開(kāi)發(fā)者請(qǐng)求修改數(shù)據(jù)庫(kù)方便陳述層的開(kāi)發(fā)，但是對(duì)數(shù)據(jù)層的設(shè)計(jì)卻是有害的。這種改變是人為的而沒(méi)考慮到其他需求的限制。這種修改經(jīng)常會(huì)違反至少損害數(shù)據(jù)的特有規(guī)則，導(dǎo)致不必要的數(shù)據(jù)冗余和數(shù)據(jù)的非標(biāo)準(zhǔn)化。

陳述層驅(qū)動(dòng)模式

陳述層驅(qū)動(dòng)模式是數(shù)據(jù)層圍繞陳述層展開(kāi)的。業(yè)務(wù)層的完成一般是通過(guò)簡(jiǎn)單的SQL查詢和很少的變化或者隔離。由于數(shù)據(jù)庫(kù)的設(shè)計(jì)是為了陳述層的方便，并非從數(shù)據(jù)層設(shè)計(jì)方面考慮，所以數(shù)據(jù)庫(kù)的設(shè)計(jì)在性能上通常很低。陳述層驅(qū)動(dòng)模式設(shè)計(jì)圖如圖1.6所示。

隔離驅(qū)動(dòng)模式

用隔離驅(qū)動(dòng)模式設(shè)計(jì)，陳述層和數(shù)據(jù)層被獨(dú)立的開(kāi)發(fā)，常常是平行開(kāi)發(fā)。這兩層在設(shè)計(jì)時(shí)沒(méi)有任何的相互干擾，所以不會(huì)存在人為的約束和有害的設(shè)計(jì)元素。當(dāng)兩層都設(shè)計(jì)完成后，再設(shè)計(jì)業(yè)務(wù)層。業(yè)務(wù)層的責(zé)任就是在沒(méi)有對(duì)數(shù)據(jù)層和陳述層的需求變化的基礎(chǔ)上完成所有的轉(zhuǎn)換。陳述層驅(qū)動(dòng)模式設(shè)計(jì)。

因?yàn)楝F(xiàn)在陳述層和數(shù)據(jù)層是完全獨(dú)立的，當(dāng)業(yè)務(wù)層需求改變的時(shí)候，陳述層和數(shù)據(jù)層都可以做相應(yīng)的修改而不影響對(duì)方。改變兩個(gè)在物理上不相鄰的層不會(huì)直接對(duì)其他層產(chǎn)生影響或發(fā)生沖突。這就允許數(shù)據(jù)層結(jié)構(gòu)的調(diào)整或者陳述層根據(jù)用戶的需求做相應(yīng)的變化，而不需要系統(tǒng)做大的調(diào)整或者修改。表1.1將對(duì)這3種驅(qū)動(dòng)模式進(jìn)行對(duì)比。

綜上所述，很容易看出隔離驅(qū)動(dòng)模式的優(yōu)點(diǎn)，隔離驅(qū)動(dòng)模式設(shè)計(jì)可以極大地提高程序的擴(kuò)展性。在1.3.2節(jié)中的應(yīng)用中就采用了三層架構(gòu)的隔離驅(qū)動(dòng)模式。

五、MVC的缺點(diǎn)

MVC的缺點(diǎn)體現(xiàn)在以下幾個(gè)方面：

1、增加了系統(tǒng)結(jié)構(gòu)和實(shí)現(xiàn)的復(fù)雜性。對(duì)于簡(jiǎn)單的界面，嚴(yán)格遵循MVC，使模型、視圖與控制器分離，會(huì)增加結(jié)構(gòu)的復(fù)雜性，并可能產(chǎn)生過(guò)多的更新操作，降低運(yùn)行效率。

2、視圖與控制器間的過(guò)于緊密的連接。視圖與控制器是相互分離，但又緊密聯(lián)系的部件，如何視圖沒(méi)有控制器的存在，那它的應(yīng)用是很有限的，反之亦然，這樣就妨礙了它們的獨(dú)立重用。

3、視圖對(duì)模型數(shù)據(jù)的低效率訪問(wèn)。依據(jù)模型操作接口的不同，視圖可能需要多次調(diào)用才能獲得足夠的顯示數(shù)據(jù)。對(duì)未變化數(shù)據(jù)的不必要的頻繁訪問(wèn)，也將損害操作性能。

4、目前，一般高級(jí)的界面工具或構(gòu)造器不支持MVC架構(gòu)。改造這些工具以適應(yīng)MVC需要和建立分離的部件的代價(jià)是很高的，從而造成使用MVC的困難。