一、什么是模式？什么是框架？
1、什么是模式？
模式，即pattern。其實就是解決某一類問題的方法論。你把解決某類問題的方法總結(jié)歸納到理論高度，那就是模式。
Alexander給出的經(jīng)典定義是：每個模式都描述了一個在我們的環(huán)境中不斷出現(xiàn)的問題，然后描述了該問題的解決方案的核心。通過這種方式，你可以無數(shù)次地使用那些已有的解決方案，無需在重復(fù)相同的工作。
模式有不同的領(lǐng)域，建筑領(lǐng)域有建筑模式，軟件設(shè)計領(lǐng)域也有設(shè)計模式。當一個領(lǐng)域逐漸成熟的時候，自然會出現(xiàn)很多模式。
2、什么是框架？
框架，即framework。其實就是某種應(yīng)用的半成品，就是一組組件，供你選用完成你自己的系統(tǒng)。簡單說就是使用別人搭好的舞臺，你來做表演。而且，框架一般是成熟的，不斷升級的軟件。
3、為什么要用模式？
因為模式是一種指導(dǎo)，在一個良好的指導(dǎo)下，有助于你完成任務(wù)，有助于你作出一個優(yōu)良的設(shè)計方案，達到事半功倍的效果。而且會得到解決問題的最佳辦法。
為什么要用框架？
因為軟件系統(tǒng)發(fā)展到今天已經(jīng)很復(fù)雜了，特別是服務(wù)器端軟件，設(shè)計到的知識，內(nèi)容，問題太多。在某些方面使用別人成熟的框架，就相當于讓別人幫你完成一些基礎(chǔ)工作，你只需要集中精力完成系統(tǒng)的業(yè)務(wù)邏輯設(shè)計。而且框架一般是成熟，穩(wěn)健的，他可以處理系統(tǒng)很多細節(jié)問題，比如，事物處理，安全性，數(shù)據(jù)流控制等問題。還有框架一般都經(jīng)過很多人使用，所以結(jié)構(gòu)很好，所以擴展性也很好，而且它是不斷升級的，你可以直接享受別人升級代碼帶來的好處。
框架一般處在低層應(yīng)用平臺（如J2EE）和高層業(yè)務(wù)邏輯之間的中間層。
軟件為什么要分層？
為了實現(xiàn)“高內(nèi)聚、低耦合”。把問題劃分開來各個解決，易于控制，易于延展，易于分配資源…總之好處很多啦
二、MVC架構(gòu)開發(fā)
MVC是一種軟件開發(fā)架構(gòu)，它包含了很多的設(shè)計模式，最為密切的有以下3種：Observer（觀察者模式）、Composite（合成模式）和Strategy（策略模式）。本節(jié)主要論述MVC架構(gòu)的原理、優(yōu)缺點以及MVC為Web應(yīng)用程序帶來的好處。
1、什么是MVC架構(gòu)
模型（Model）－視圖（View）－控制器（Controller）即為MVC，MVC在八十年代為編程語言Smalltalk－80發(fā)明的一種軟件架構(gòu)模式，至今已被廣泛使用。模型－視圖－控制器模式是一個有用的工具箱，但它也存在一些不足。
2、MVC工作原理
MVC是一個設(shè)計模式，它使應(yīng)用程序的輸入、處理和輸出強制性分開，使得軟件可維護性、可擴展性、靈活性以及封裝性得到提高。使用MVC應(yīng)用程序被分成三個核心部件：M（模型）、V（視圖）、C（控制器）。模型是所有的商業(yè)邏輯代碼片段所在。視圖表示數(shù)據(jù)在屏幕上的顯示。控制器提供處理過程控制，它在模型和視圖之間起連接作用?？刂破鞅旧聿惠敵鋈魏涡畔⒑妥鋈魏翁幚?，它只負責把用戶的請求轉(zhuǎn)成針對Model的操作，和調(diào)用相應(yīng)的視圖來顯示Model處理后的數(shù)據(jù)。三者之間關(guān)系。
MVC（Model-View-Controller）把系統(tǒng)的組成分解為M（模型）、V（視圖）、C（控制器）三種部件。下面分別對這三個核心部件進行介紹。
模型
模型表示企業(yè)數(shù)據(jù)和業(yè)務(wù)規(guī)則。在MVC的三個部件中，模型擁有最多的處理任務(wù)。被模型返回的數(shù)據(jù)是中立的，就是說模型與數(shù)據(jù)格式無關(guān)，這樣一個模型能為多個視圖提供數(shù)據(jù)。由于應(yīng)用于模型的代碼只需寫一次就可以被多個視圖重用，所以減少了代碼的重復(fù)性。
視圖
視圖是用戶可以看到并與之交互的界面。視圖就是由HTML元素組成的界面，HTML依舊在視圖中扮演著重要的角色，但一些新的技術(shù)已層出不窮，它們包括MacromediaFlash、XHTML、XML/XSL、WML等一些標識語言和WebServices等。
如何處理應(yīng)用程序的界面變得越來越有挑戰(zhàn)性。MVC有一個突出的優(yōu)點是能為應(yīng)用程序處理很多不同的視圖，在視圖中其實沒有真正的處理發(fā)生，不管這些數(shù)據(jù)是聯(lián)機存儲的還是本地儲存，作為視圖來講，它只是作為一種輸出數(shù)據(jù)并允許用戶操縱的方式。
控制器
現(xiàn)在總結(jié)ＭVC的處理過程，首先控制器接收用戶的請求，并決定應(yīng)該調(diào)用哪個模型來進行處理，然后模型用業(yè)務(wù)邏輯來處理用戶的請求并返回數(shù)據(jù)，最后控制器用相應(yīng)的視圖格式化模型返回的數(shù)據(jù)，并通過表示層呈現(xiàn)給用戶。
三、為什么要使用MVC架構(gòu)
ASP.NET提供了一個很好的實現(xiàn)這種經(jīng)典設(shè)計模式的環(huán)境。程序人員通過在ASPX頁面中開發(fā)用戶接口來實現(xiàn)視圖，控制器的功能在邏輯功能代碼（.cs）中實現(xiàn)，模型通常對應(yīng)系統(tǒng)的業(yè)務(wù)部分。在ASP.NET中實現(xiàn)這種設(shè)計而提供的一個多層系統(tǒng)，將數(shù)據(jù)（模型）從對其操作的動作（控制器）分離出來可以設(shè)計一個與后臺存儲數(shù)據(jù)無關(guān)的系統(tǒng)，就MVC結(jié)構(gòu)的本質(zhì)而言，它是一種解決耦合系統(tǒng)問題的方法。
在ASP.NET中編寫MVC模式具有極其良好的可擴展性。它可以輕松實現(xiàn)以下功能：
實現(xiàn)一個模型的多個視圖
采用多個控制器
當模型改變時，所有視圖將自動刷新
所有的控制器將相互獨立工作
這就是MVC架構(gòu)的好處，只需在以前的程序上稍作修改或增加新的類，即可增添程序的功能。以前開發(fā)的類可以重用，而程序結(jié)構(gòu)根本不再需要改變，各類之間相互獨立，便于團體開發(fā)，提高開發(fā)效率。
下面介紹一下使用MVC架構(gòu)的優(yōu)點：
1、提高代碼重用率
最重要的一點是多個視圖能共享一個模型，無論用戶想要Flash界面或是WAP界面；用一個模型就能處理它們。由于已經(jīng)將數(shù)據(jù)和業(yè)務(wù)規(guī)則從表示層分開，所以可以最大化的重用代碼。
2、提高程序的可維護性
因為模型是自包含的，并且與控制器和視圖相分離，所以很容易改變數(shù)據(jù)層和業(yè)務(wù)規(guī)則。例如，把數(shù)據(jù)庫從SQLServer移植到Oracle，只需改變模型即可。一旦正確的實現(xiàn)了模型，不管數(shù)據(jù)來自哪里，視圖都會正確的顯示它們。MVC架構(gòu)的運用，使得程序的三個部件相互對立，大大提高了程序的可維護性。
3、有利于團隊開發(fā)
在開發(fā)過程中，可以更好地分工，更好地協(xié)作。有利于開發(fā)出高質(zhì)量的軟件。良好的項目架構(gòu)設(shè)計，將減少編碼工作量。采用MVC結(jié)構(gòu)和代碼生成器，是大多數(shù)Web應(yīng)用程序的理想選擇。部分模型（Model）和存儲過程一般可用工具自動生成。控制器（Controller）比較穩(wěn)定，一般由架構(gòu)師（或經(jīng)驗豐富程序人員）完成；那么整個項目需要手動編寫代碼的地方就只有視圖(View)了。在這種模式下，個人能力不是特別重要，只要懂點語法基礎(chǔ)的人都可以編寫，無論項目成員寫出什么樣的代碼，都在項目管理者的可控范圍內(nèi)。即使開放項目途中人員流動，也不會有太大問題。在個人能力不均衡的團隊開發(fā)中，采用MVC開發(fā)是非常理想的。
另外，MVC架構(gòu)可以實現(xiàn)一個模型、兩個視圖和一個控制器的程序。下面將討論如何實現(xiàn)一個模型、兩個視圖和一個控制器的程序。其中模型類及視圖類根本不需要改變，與前面的完全一樣，這就是面向?qū)ο缶幊痰暮锰帯τ诳刂破髦械念?，只需要增加另一個視圖，并與模型發(fā)生關(guān)聯(lián)即可。
同樣也可以實現(xiàn)其他形式的MVC。例如：一個模型、兩個視圖和兩個控制器。從上面可以看出，通過MVC模式實現(xiàn)的應(yīng)用程序具有極其良好的可擴展性，是ASP.NET面向?qū)ο缶幊痰奈磥矸较颉?div style="height:15px;">
四、表示層——業(yè)務(wù)邏輯層——數(shù)據(jù)訪問層
1、什么是三層架構(gòu)
所謂的三層開發(fā)就是將系統(tǒng)的整個業(yè)務(wù)應(yīng)用劃分為表示層——業(yè)務(wù)邏輯層——數(shù)據(jù)訪問層，這樣有利于系統(tǒng)的開發(fā)、維護、部署和擴展。
分層是為了實現(xiàn)“高內(nèi)聚、低耦合”。采用“分而治之”的思想，把問題劃分開來各個解決，易于控制，易于延展，易于分配資源。
表示層：負責直接跟用戶進行交互，一般也就是指系統(tǒng)的界面，用于數(shù)據(jù)錄入，數(shù)據(jù)顯示等。意味著只做與外觀顯示相關(guān)的工作，不屬于他的工作不用做。
業(yè)務(wù)邏輯層：用于做一些有效性驗證的工作，以更好地保證程序運行的健壯性。如完成數(shù)據(jù)添加、修改和查詢業(yè)務(wù)等；不允許指定的文本框中輸入空字符串，數(shù)據(jù)格式是否正確及數(shù)據(jù)類型驗證；用戶的權(quán)限的合法性判斷等等，通過以上的諸多判斷以決定是否將操作繼續(xù)向后傳遞，盡量保證程序的正常運行。
數(shù)據(jù)訪問層：顧名思義，就是用于專門跟數(shù)據(jù)庫進行交互。執(zhí)行數(shù)據(jù)的添加、刪除、修改和顯示等。需要強調(diào)的是，所有的數(shù)據(jù)對象只在這一層被引用，如System.Data.SqlClient等，除數(shù)據(jù)層之外的任何地方都不應(yīng)該出現(xiàn)這樣的引用。
ASP.NET可以使用.NET平臺快速方便地部署三層架構(gòu)。ASP.NET革命性的變化是在網(wǎng)頁中也使用基于事件的處理，可以指定處理的后臺代碼文件，可以使用C#、VB、C++和J#作為后臺代碼的語言。.NET中可以方便的實現(xiàn)組件的裝配，后臺代碼通過命名空間可以方便的使用自己定義的組件。顯示層放在ASPX頁面中，數(shù)據(jù)庫操作和邏輯層用組件或封裝類來實現(xiàn)，這樣就很方便的實現(xiàn)了三層架構(gòu)。
2、為什么使用三層架構(gòu)
對于一個簡單的應(yīng)用程序來說，代碼量不是很多的情況下，一層結(jié)構(gòu)或二層結(jié)構(gòu)開發(fā)完全夠用，沒有必要將其復(fù)雜化，如果對一個復(fù)雜的大型系統(tǒng)，設(shè)計為一層結(jié)構(gòu)或二層結(jié)構(gòu)開發(fā)，那么這樣的設(shè)計存在很嚴重缺陷。下面會具體介紹，分層開發(fā)其實是為大型系統(tǒng)服務(wù)的。
在開發(fā)過程中，初級程序人員出現(xiàn)相似的功能經(jīng)常復(fù)制代碼，那么同樣的代碼為什么要寫那么多次？不但使程序變得冗長，更不利于維護，一個小小的修改或許會涉及很多頁面，經(jīng)常導(dǎo)致異常的產(chǎn)生使程序不能正常運行。最主要的面向?qū)ο蟮乃枷霙]有得到絲毫的體現(xiàn)，打著面向?qū)ο蟮幕献訁s依然走著面向過程的道路。
意識到這樣的問題，初級程序人員開始將程序中一些公用的處理程序?qū)懗晒卜椒ǎ庋b在類中，供其它程序調(diào)用。例如寫一個數(shù)據(jù)操作類，對數(shù)據(jù)操作進行合理封裝，在數(shù)據(jù)庫操作過程中，只要類中的相應(yīng)方法（數(shù)據(jù)添加、修改、查詢等）可以完成特定的數(shù)據(jù)操作，這就是數(shù)據(jù)訪問層，不用每次操作數(shù)據(jù)庫時都寫那些重復(fù)性的數(shù)據(jù)庫操作代碼。在新的應(yīng)用開發(fā)中，數(shù)據(jù)訪問層可以直接拿來用。面向?qū)ο蟮娜筇匦灾坏姆庋b性在這里得到了很好的體現(xiàn)。讀者現(xiàn)在似乎找到了面向?qū)ο蟮母杏X，代碼量較以前有了很大的減少，而且修改的時候也比較方便，也實現(xiàn)了代碼的重用性。
下面舉兩個案例，解釋一下為什么要使用三層架構(gòu)。
案例一：
數(shù)據(jù)庫系統(tǒng)軟件由于數(shù)據(jù)量的不斷增加，數(shù)據(jù)庫由Access變成了SQLServer數(shù)據(jù)庫，這樣原來的數(shù)據(jù)訪問層失效了，數(shù)據(jù)操作對象發(fā)生了變化，并且頁面中涉及數(shù)據(jù)對象的地方也要進行修改，因為原來可能會使用OleDbDataReader對象將數(shù)據(jù)傳遞給顯示頁面，現(xiàn)在都得換成SqlDataReader對象，SQLServer和Access支持的數(shù)據(jù)類型也不一致，在顯示數(shù)據(jù)時進行的數(shù)據(jù)轉(zhuǎn)換也要進行修改，這是其中一種情況。
案例二：
由于特殊情況需要，把Web形式的項目改造成Windows應(yīng)用，此時需要做多少修改呢？如果在Aspx.cs中占據(jù)了大量代碼，或者還有部分代碼存在于Aspx中，那么整個系統(tǒng)是否需要重新來開發(fā)呢？
在上面的案例中是否體會到了沒有分層開發(fā)模式的缺陷呢？是否碰到過這樣的情況呢？這都是由設(shè)計不合理造成的，多層開發(fā)架構(gòu)的出現(xiàn)可以很好地解決該問題，通過程序架構(gòu)進行合理的分層，將極大地提高程序的通用性。
3、使用三層架構(gòu)開發(fā)的優(yōu)點
使用三層架構(gòu)開發(fā)有以下優(yōu)點：
從開發(fā)角度和應(yīng)用角度來看，三層架構(gòu)比二層架構(gòu)或單層架構(gòu)都有更大的優(yōu)勢。三層架構(gòu)適合團隊開發(fā)，每人可以有不同的分工，協(xié)同工作使效率倍增。開發(fā)二層或單層應(yīng)用程序時，每個開發(fā)人員都應(yīng)對系統(tǒng)有較深的理解，能力要求很高，開發(fā)三層應(yīng)用程序時，則可以結(jié)合多方面的人才，只需少數(shù)人對系統(tǒng)全面了解即可，從一定程度降低了開發(fā)的難度。
三層架構(gòu)可以更好的支持分布式計算環(huán)境。邏輯層的應(yīng)用程序可以在多個計算機上運行，充分利用網(wǎng)絡(luò)的計算功能。分布式計算的潛力巨大，遠比升級CPU有效。美國人曾利用分式計算解密，幾個月就破解了據(jù)稱永遠都破解不了的密碼。
三層架構(gòu)的最大優(yōu)點是它的安全性。用戶只能通過邏輯層來訪問數(shù)據(jù)層，減少了入口點，把很多危險的系統(tǒng)功能都屏蔽了。
4、三層架構(gòu)的種類
目前，團隊開發(fā)人員在開發(fā)項目時，大多都使用分層開發(fā)架構(gòu)設(shè)計，最常見的就是三層架構(gòu)，目的在于使各個層之間只能夠被它相鄰的層產(chǎn)生影響，但是這個限制常常在使用多層開發(fā)的時候被違反，這對系統(tǒng)的開發(fā)是有害的。三層架構(gòu)按驅(qū)動模式可劃分三種：數(shù)據(jù)層驅(qū)動模式、陳述層驅(qū)動模式和隔離驅(qū)動模式，其中隔離驅(qū)動模式開發(fā)最為重要。下面通過三種模式的對比，介紹隔離驅(qū)動模式的重要性。
數(shù)據(jù)層驅(qū)動模式
所謂的數(shù)據(jù)層驅(qū)動模式，就是先設(shè)計數(shù)據(jù)層，陳述層圍繞數(shù)據(jù)層展開，一旦完成了數(shù)據(jù)層和陳述層，業(yè)務(wù)層就圍繞數(shù)據(jù)層展開。因為陳述層是圍繞數(shù)據(jù)層展開的，這將會使陳述層中的約束不準確，并且限制了業(yè)務(wù)層的變更。由于業(yè)務(wù)層受到限制，一些簡單變化可以通過SQL查詢和存儲過程來實現(xiàn)。
這種模式非常的普遍，它和傳統(tǒng)的客戶服務(wù)端開發(fā)相似，并且是圍繞已經(jīng)存在的數(shù)據(jù)庫設(shè)計的。由于陳述層是圍繞數(shù)據(jù)層設(shè)計的，它常常是憑直覺模仿數(shù)據(jù)層的實際結(jié)構(gòu)。
常常存在一種額外的反饋循環(huán)在陳述層到數(shù)據(jù)之間，當在設(shè)計陳述層不容易實現(xiàn)的時候常常會去修改數(shù)據(jù)層，也就形成了這種反饋循環(huán)。開發(fā)者請求修改數(shù)據(jù)庫方便陳述層的開發(fā)，但是對數(shù)據(jù)層的設(shè)計卻是有害的。這種改變是人為的而沒考慮到其他需求的限制。這種修改經(jīng)常會違反至少損害數(shù)據(jù)的特有規(guī)則，導(dǎo)致不必要的數(shù)據(jù)冗余和數(shù)據(jù)的非標準化。
陳述層驅(qū)動模式
陳述層驅(qū)動模式是數(shù)據(jù)層圍繞陳述層展開的。業(yè)務(wù)層的完成一般是通過簡單的SQL查詢和很少的變化或者隔離。由于數(shù)據(jù)庫的設(shè)計是為了陳述層的方便，并非從數(shù)據(jù)層設(shè)計方面考慮，所以數(shù)據(jù)庫的設(shè)計在性能上通常很低。陳述層驅(qū)動模式設(shè)計圖如圖1.6所示。
隔離驅(qū)動模式
用隔離驅(qū)動模式設(shè)計，陳述層和數(shù)據(jù)層被獨立的開發(fā)，常常是平行開發(fā)。這兩層在設(shè)計時沒有任何的相互干擾，所以不會存在人為的約束和有害的設(shè)計元素。當兩層都設(shè)計完成后，再設(shè)計業(yè)務(wù)層。業(yè)務(wù)層的責任就是在沒有對數(shù)據(jù)層和陳述層的需求變化的基礎(chǔ)上完成所有的轉(zhuǎn)換。陳述層驅(qū)動模式設(shè)計。
因為現(xiàn)在陳述層和數(shù)據(jù)層是完全獨立的，當業(yè)務(wù)層需求改變的時候，陳述層和數(shù)據(jù)層都可以做相應(yīng)的修改而不影響對方。改變兩個在物理上不相鄰的層不會直接對其他層產(chǎn)生影響或發(fā)生沖突。這就允許數(shù)據(jù)層結(jié)構(gòu)的調(diào)整或者陳述層根據(jù)用戶的需求做相應(yīng)的變化，而不需要系統(tǒng)做大的調(diào)整或者修改。表1.1將對這3種驅(qū)動模式進行對比。
表種驅(qū)動模式對比
數(shù)據(jù)層驅(qū)動模式
陳述層驅(qū)動模式
隔離驅(qū)動模式
數(shù)據(jù)庫
（1）很容易設(shè)計
（2）產(chǎn)生負面影響
（3）很難改變數(shù)據(jù)層，因為它和陳述層緊密綁定
（1）數(shù)據(jù)庫設(shè)計很糟
（2）嚴重的不規(guī)范化設(shè)計
（3）其他系統(tǒng)不易使用
（4）很難改變數(shù)據(jù)層，由于它跟陳述層緊密綁定
（1）優(yōu)化設(shè)計
（2）集中設(shè)計數(shù)據(jù)庫，陳述層對它影響很小
業(yè)務(wù)需求
常常不能適應(yīng)業(yè)務(wù)需求變化
常常適應(yīng)業(yè)務(wù)需求變化
適應(yīng)需求變化
用戶界面
是圍繞數(shù)據(jù)層而不是圍繞用戶，不易修改
適合用戶擴展界面
適合用戶擴展界面
擴展性
通?？蓴U張，但是常常在用戶界面需要比較多的重寫以滿足數(shù)據(jù)庫的結(jié)構(gòu)，同時數(shù)據(jù)庫可能需要存儲一些冗余的字段
完整性的擴張很難，常常只有通過“剪切，粘貼”函數(shù)來實現(xiàn)
很容易擴展
綜上所述，很容易看出隔離驅(qū)動模式的優(yōu)點，隔離驅(qū)動模式設(shè)計可以極大地提高程序的擴展性。在1.3.2節(jié)中的應(yīng)用中就采用了三層架構(gòu)的隔離驅(qū)動模式。
五、MVC的缺點
MVC的缺點體現(xiàn)在以下幾個方面：
1、增加了系統(tǒng)結(jié)構(gòu)和實現(xiàn)的復(fù)雜性。對于簡單的界面，嚴格遵循MVC，使模型、視圖與控制器分離，會增加結(jié)構(gòu)的復(fù)雜性，并可能產(chǎn)生過多的更新操作，降低運行效率。
2、視圖與控制器間的過于緊密的連接。視圖與控制器是相互分離，但又緊密聯(lián)系的部件，如何視圖沒有控制器的存在，那它的應(yīng)用是很有限的，反之亦然，這樣就妨礙了它們的獨立重用。
3、視圖對模型數(shù)據(jù)的低效率訪問。依據(jù)模型操作接口的不同，視圖可能需要多次調(diào)用才能獲得足夠的顯示數(shù)據(jù)。對未變化數(shù)據(jù)的不必要的頻繁訪問，也將損害操作性能。
4、目前，一般高級的界面工具或構(gòu)造器不支持MVC架構(gòu)。改造這些工具以適應(yīng)MVC需要和建立分離的部件的代價是很高的，從而造成使用MVC的困難。
