MVC的優點 大部分用過程語言比如ASP、PHP開發出來的Web應用，初始的開發模板就是混合層的數據編程。例如，直接向數據庫發送請求並用HTML顯示,開發速度往往比較快,但由於數據頁面的分離不是很直接,因而很難體現出業務模型的樣子或者模型的重用性。產品設計彈性力度很小，很難滿足用戶的變化性需求。MVC要求對應用分層，雖然要花費額外的工作，但產品的結構清晰，產品的應用通過模型可以得到更好地體現。 首先，最重要的是應該有多個視圖對應一個模型的能力。在目前用戶需求的快速變化下，可能有多種方式訪問應用的要求。例如，訂單模型可能有本系統的訂單，也有網上訂單，或者其他系統的訂單，但對於訂單的處理都是一樣，也就是說訂單的處理是一致的。按MVC設計模式，一個訂單模型以及多個視圖即可解決問題。這樣減少了代碼的復制，即減少了代碼的維護量，一旦模型發生改變，也易於維護。 其次，由於模型返回的數據不帶任何顯示格式，因而這些模型也可直接應用於接口的使用。 再次，由於一個應用被分離為三層，因此有時改變其中的一層就能滿足應用的改變。一個應用的業務流程或者業務規則的改變只需改動MVC的模型層。 控制層的概念也很有效，由於它把不同的模型和不同的視圖組合在一起完成不同的請求，因此，控制層可以說是包含了用戶請求權限的概念。 最后，它還有利於軟件工程化管理。由於不同的層各司其職，每一層不同的應用具有某些相同的特征，有利於通過工程化、工具化產生管理程序代碼。 MVC的不足 MVC的不足體現在以下幾個方面： （1）增加了系統結構和實現的復雜性。對於簡單的界面，嚴格遵循MVC，使模型、視圖與控制器分離，會增加結構的復雜性，並可能產生過多的更新操作，降低運行效率。 （2）視圖與控制器間的過於緊密的連接。視圖與控制器是相互分離，但確實聯系緊密的部件，視圖沒有控制器的存在，其應用是很有限的，反之亦然，這樣就妨礙了他們的獨立重用。 （3）視圖對模型數據的低效率訪問。依據模型操作接口的不同，視圖可能需要多次調用才能獲得足夠的顯示數據。對未變化數據的不必要的頻繁訪問，也將損害操作性能。 （4） 目前，一般高級的界面工具或構造器不支持MVC架構。改造這些工具以適應MVC需要和建立分離的部件的代價是很高的，從而造成使用MVC的困難。
MVC 和三層架構 首先、它們很相似； MVC 可分為： Model 模型層、 View 視圖層、 Controller 控制層； 三層架構為：視圖層、控制層、業務邏輯層 + 數據訪問層。 如此分包法， 層次上的結構雖清晰， 而且很大程度地減少了模塊之間的耦合度， 但這樣 同時也添加了些許麻煩。 小的項目這樣分層， 分包， 不太符合實際； 但對於大中型項目這樣 的分工是太有必要了，視圖層、控制層、業務邏輯層、數據訪問層，目前我們只要知道這是 最合理的分層模式就可以了。 架構中，我們可以如此分布： 控制層 + （ （模型層 + 數據訪問層） + 視圖層） = 合理架構。 數據模型層 顧名思義，用來和數據庫進行連接交互， SQL 語句當然應該置於此。 模型層中數據訪問模塊的功能如下： 1) 實現數據的讀取與存儲操作。 2) 實現事務處理。 界面視圖層 主要是處理和用戶進行交互的界面，顯示結果或者接受輸入。 視圖層中用戶界面模塊的功能如下： 1) 與用戶的交互，接收用戶的各種輸入以及輸出各種提示信息或處理結果。 2) 對於輸入的數據進行數據校驗，過濾非法數據。 3) 向業務層發送處理請求。 業務控制層 進行各種邏輯判斷。也就是業務邏輯的封裝，如有一客戶要下一個用賬戶付款的訂單， 但該客戶賬戶內的余額不夠，則不該允許此客戶下訂單，這種邏輯就應放在業務層。 業務層中業務處理模塊的功能如下： 1) 實現各種業務處理邏輯或處理算法。 2) 驗證請求者的權限。 3) 向數據層發送數據操作的請求。 4) 向用戶層返回處理結果。 針對每一層可以設計一個或多個模塊，每個模塊完成相對獨立的功能。 邏輯架構總結 邏輯架構定義了如何分離應用程序中不同的代碼。 一個好的邏輯架構的目的是使代碼更 容易維護、 理解和可重用性。 而物理架構的定義則指定了運行應用程序的電腦， 一個好的物 理架構目的在於使系統在性能、 可擴展性、 安全性和容錯能力之間取得最好的平衡， 來滿足 你的特定環境。 分層架構的主要優點是分化了系統的復雜度， 同時也提高了系統的靈活性 （這點從系統 同時滿足各種類型數據庫即可看出） ，另外，分層架構大大提高了系統的可維護性和可擴展 性。 但是， 分層架構在眾多優點的背后也隱藏着缺點， 由於層次的增多， 同一個解決方案下 項目也多， 過多的跨項目訪問對應用程序的效率有一定的影響， 但這一點現在可以在越來越 快的硬件提升速度中忽略。
三層架構(3-tier application) 通常意義上的三層架構就是將整個業務應用划分為：表現層（UI）、業務邏輯層（BLL）、數據訪問層（DAL）。區分層次的目的即為了“高內聚，低耦合"的思想。 １、表現層（UI）：通俗講就是展現給用戶的界面，即用戶在使用一個系統的時候他的所見所得。 ２、業務邏輯層（BLL）：針對具體問題的操作，也可以說是對數據層的操作，對數據業務邏輯處理。 ３、數據訪問層（DAL）：該層所做事務直接操作數據庫，針對數據的增添、刪除、修改、更新、查找等。 注：（內聚：一個模塊內各個元素彼此結合的緊密程度；耦合：一個軟件結構內不同模塊之間互連程度的度量） 優缺點 優點： 1、開發人員可以只關注整個結構中的其中某一層； 2、可以很容易的用新的實現來替換原有層次的實現； 3、可以降低層與層之間的依賴； 4、有利於標准化； 5、利於各層邏輯的復用。 6、擴展性強。不同層負責不同的層面，如PetShop可經過簡單的配置實現Sqlserver和oracle之間的轉換，當然寫好了也可以實現B/S與C/S之間的轉換 7、安全性高。用戶端只能通過邏輯層來訪問數據層，減少了入口點，把很多危險的系統功能都屏蔽了。 8、項目結構更清楚，分工更明確，有利於后期的維護和升級 缺點： 1、降低了系統的性能。這是不言而喻的。如果不采用分層式結構，很多業務可以直接造訪數據庫，以此獲取相應的數據，如今卻必須通過中間層來完成。 2、有時會導致級聯的修改。這種修改尤其體現在自上而下的方向。如果在表示層中需要增加一個功能，為保證其設計符合分層式結構，可能需要在相應的業務邏輯層和數據訪問層中都增加相應的代碼 3、增加了代碼量，增加了工作量 三層架構是： 一：界面層 界面層提供給用戶一個視覺上的界面，通過界面層，用戶輸入數據、獲取數據。界面層同時也提供一定的安全性，確保用戶不用看到不必要的機密信息。 二：邏輯層 邏輯層是界面層和數據層的橋梁，它響應界面層的用戶請求，執行任務並從數據層抓取數據，並將必要的數據傳送給界面層。 三：數據層 數據層定義、維護數據的完整性、安全性，它響應邏輯層的請求，訪問數據。這一層通常由大型的數據庫服務器實現，如Oracle 、Sybase、MS SQl Server等。 ------ 從開發角度和應用角度來看，三層架構比雙層或單層結構都有更大的優勢。三層結構適合群體開發，每人可以有不同的分工，協同工作使效率倍增。開發雙層或單層應用時，每個開發人員都應對系統有較深的理解，能力要求很高，開發三層應用時，則可以結合多方面的人才，只需少數人對系統全面了解，從一定程度工降低了開發的難度。 三層架構屬於瘦客戶的模式，用戶端只需一個較小的硬盤、較小的內存、較慢的CPU就可以獲得不錯的性能。相比之下，單層或胖客戶對面器的要求太高。 三層架構的另一個優點在於可以更好的支持分布式計算環境。邏輯層的應用程序可以有多個機器上運行，充分利用網絡的計算功能。分布式計算的潛力巨大，遠比升級CPU有效。 三層架構的最大優點是它的安全性。用戶端只能通過邏輯層來訪問數據層，減少了入口點，把很多危險的系統功能都屏蔽了。 另外三層架構還可以支持如下功能：Remote Access(遠程訪問資料)，例如可透過Internet存取遠程數據庫；High Performance(提升運算效率)解決集中式運算(Centralize)及主從式架構(Client-Server)中，數據庫主機的運算負擔，降低數據庫主機的Connection Load，並可藉由增加App Server處理眾多的數據處理要求，這一點跟前面講到的分布式計算提高運算能力是一個道理；Client端發出Request(工作要求)后，便可離線，交由App Server和DataBase Server共同把工作完成，減少Client端的等待時間；這個功能我覺得應用場合不是很多，自己感受也不是很深刻，從理論上是成立的。 小項目，以后變動不大的不用三層架構。 ASP.NET三層結構說明 完善的三層結構的要求是:修改表現層而不用修改邏輯層,修改邏輯層而不用修改數據層。否則你的應用是不是多層結構,或者說是層結構的划分和組織上是不是有問題就很難說.不同的應用有不同的理解，這只是一個概念的問題． 理解ASP.NET三層結構——為什么要分三層？ 我們用三層結構主要是使項目結構更清楚，分工更明確，有利於后期的維護和升級。它未必會提升性能，因為當子程序模塊未執行結束時，主程序模塊只能處於等待狀態。這說明將應用程序划分層次，會帶來其執行速度上的一些損失。但從團隊開發效率角度上來講卻可以感受到大不相同的效果。 需要說明一下，三層結構不是.NET的專利，也不是專門用在數據庫上的技術。它是一種更加普適的架構設計理念。 此種架構要在數據庫設計上注意表之間的關系，盡力滿足主與子的關系。在功能上對用戶要有一定的限制，不要表現在對於子表的刪除操作一定要慎重，以免造成主表與子表的數據在邏輯上出現的主表的外鍵在子表中沒有相對應的值。 對於表的綜合查詢方法是： 先對主表查詢，調用主表所對應的DL。再根據主表的記錄分別對每一個子表進行查詢。將自表的查詢結果添加的主表后，形成一個大的查詢集合。 對於表的操作（增刪改）： 此時只對主表進行操作，調用主表對應的DL中的操作方法。 RL層是邏輯判斷層，主要是對頁面上傳入的數據進行邏輯判斷。RL層之上就是UI