潛水多年，今天終于申請開通了博客。多次給朋友說過要寫幾篇文章，可是一次又一次地讓觀眾失望。今天總算出來亮了個像。申請這個博客空間一來是將自己平時遇到的問題和心得記下來與朋友共享，二來是為了鞭策自己不斷學習。

　　廢話少說，步入正題。話說今天在園子的首頁看到一篇文章，講的是關于三層架構和MVC設計模式。文章洋洋灑灑寫了一大篇。其中不乏作者對三層架構和MVC的理解和對比。作者在大談三層架構和MVC的優缺點的時卻不知三層架構并非MVC。他們是完全不同的兩個設計理念。這不禁讓我想起了一次面試。當時我問一個求職者如何理解三層架構？答曰：結構清晰、便于重用...。說了一大篇關于三層架構的優點和缺點。說得我是連連點頭。隨后問道：“你認為為何在開發當中要采用MVC設計模式呢？”。答曰：MVC即三層架構。我當場傻眼了。

　　相信將三層架構和MVC混為一談的人大有人在。在此，我想說說我對三層（多層）架構和MVC的一些淺見。要想深入解一門技術，首先知道為何會出現這門技術？它是為了解什么問題而出來的？清楚了這些問題，在隨后的學習中自然就會順風順水，而不是一頭霧水。

　　三層（多層）架構

　　就拿B/S開發說起。最初的ASP直接把數據庫訪問代碼寫在頁面上。整個網站就是幾個頁面。數據訪問、業務控制、界面顯示全都在一個文件里。這種設計可以理解為一層架構。因為它沒有分層的概念。在這樣的開發模式下，同樣的邏輯代碼經常出現在多個地方。當有相似的功能需要實現時，直接拷貝代碼到另一個地方，然后修改。如果遇到系統升級或業務規則發生變化，必須找遍整個系統并作調整。這樣的設計不僅工作量大，而且不利于維護。往往一個程序員必須熟悉數據訪問和業務規則，同時還得精通頁面的編寫，因為要寫完一個功能就必須把這些內容全部寫在頁面上。JSP程序員在開發一個功能時會寫兩樣東西jsp和JavaBean。JaveBean封裝了數據訪問和業務邏輯，jsp頁面調然JavaBean的接口，然后將數據顯示在頁面上。這樣如果有多個頁面需要用到相同的業務規則只需調用同一個JavaBean封裝好的接口即可。如果修改了業務規則直接修改JavaBean而不用到每個頁面上去尋找相同的代碼。同時也使得業務邏輯實現人員可以和界面開發人員分工合作。這種設計可以理解為兩層架構（表現層、數據訪問+業務邏輯）。隨著編程技術的發展，人們發現不同的業務規則里可能會用到相同的數據。如果按照原來的設計方式同樣存在許多重復的代碼在JavaBean里。所以后來就將數據訪問和業務邏輯再次細分。形成了表現層+業務邏輯層+數據訪問層這種架構。當然，隨著技術的發展和系統復雜程序的增加，一個系統還可能存在其它的“層”，如：權限驗證層、對象緩存層等。

　　三層（多層）架構的出現，使得程序編寫的代碼得以重用，程序員之間可以更好地分工合作，程序架構更加清晰并易于維護。但三層（多層）架構并非適合于所有的項目開發。原先獲取一個數據只需直接從數據庫查詢出來即可。用到了三層（多層）架構后還得先通過業務邏輯層，然后數據訪問層才可以得到。原來一個類或一段代碼就可以完成的操作變成了好幾個類協作才能完成。如果項目規模并不大，采用這樣的多層架構就像殺雞用牛刀一樣反而不順手了。所以，多層架構適用于需要協同開發且具有一定規模或業務較復雜的系統。同時由于分了多層，一個接口的變化可能會引起多層接口的修改。

　　MVC（Model-View-Controller）設計模式

　　MVC是一種非常經典的設計模式。它廣泛應用于各種語言和各種類型的應用中。MVC的思想是將“顯示”（View）、“數據”(Model)和“控制”(Control)分開。View部分負責向用戶展示數據和接收用戶輸入Control負責接收View傳來的輸入并執行相應的業務邏輯獲得執行結果，然后再調用View將結果向用戶呈現。Model是輸入和輸出的數據載體。MVC將顯示和控制分開，使得View的變化不會影響到Control的修改，同時同樣的數據可能會提交到不同的View進行顯示。MVC和多層架構一樣，提高了系統的可維護性、可擴展性和可移植性。

　　現在各種開發語言都有很多框架和技術支持MVC這種設計模式。在JAVA里有開源框架Struts、Spring MVC、JSF等。它們通常都是利用Servlet作Control，利用模板語言作為View。而.net也推出了自己的MVC框架，最近推出了MVC2.0（在vs2008下支持）。這一切都顯示了MVC設計模式的強大生命力。要想學習MVC設計模式必須深入理解三個部分的作用并從根本上改變以前開發當中的設計思路，不然用到MVC設計模式會覺得處處受牽制。

　　對于大多數朋友會認為三層架構就是MVC的原因，我想可能是因為MVC和三層架構都是分三個部分吧。多層架構的思想是低層為上層服務，上層調用低層時根本不用關心具體實現（所以在多層架構中通常是通過接口進行調用，而非具體的實現對象）。MVC則是分工合作，相互協調。另外還有兩點需要說明一下。

　　一，MVC中的Model和三層架構中用到的Model在概念上并非同一對象(雖然在大多數情況下是同樣的類在擔當這個職責)。MVC中的Model是值對象(Value Object 簡稱VO)，其職責是封裝需要傳遞到View進行顯示的數據。三層架構中的Model是業務對象(Business Object簡稱BO)，其職責是在處理業務邏輯時進行數據傳遞。在有些復雜的系統中還有持久對象（Persistant Object簡稱PO）。

　　二，webform不是MVC。在webform中代碼文件（通常是“頁面名稱.aspx.cs”）是繼承于System.Web.UI.Page，而頁面又繼承于代碼文件中的類。它并不存在View和Control。

?

　　后話：多層架構和MVC都是前人的經驗總結。好好利用多層架構和MVC可以開發出健壯、易于擴展的系統。而軟件開發人員必須深入理解這些設計模式的精髓方能靈活應用，否則將會深受其害，在開發中處處受制。

轉載于:https://www.cnblogs.com/leo_gu/archive/2010/04/28/1723397.html

總結

以上是生活随笔為你收集整理的谈谈多层架构和MVC的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。