MVC設計模式與多層架構
多層架構
就拿B/S開發說起。最初的ASP直接把數據庫訪問代碼寫在頁面上。整個網站就是幾個頁面。數據訪問、業務控制、界面顯示全都在一個文件裏。這種設計可以理解爲一層架構。因爲它沒有分層的概念。在這樣的開發模式下，同樣的邏輯代碼經常出現在多個地方。當有相似的功能需要實現時，直接拷貝代碼到另一個地方，然後修改。如果遇到系統升級或業務規則發生變化，必須找遍整個系統並作調整。這樣的設計不僅工作量大，而且不利於維護。往往一個程序員必須熟悉數據訪問和業務規則，同時還得精通頁面的編寫，因爲要寫完一個功能就必須把這些內容全部寫在頁面上。JSP程序員在開發一個功能時會寫兩樣東西jsp和JavaBean。JaveBean封裝了數據訪問和業務邏輯，jsp頁面調然JavaBean的接口，然後將數據顯示在頁面上。這樣如果有多個頁面需要用到相同的業務規則只需調用同一個JavaBean封裝好的接口即可。如果修改了業務規則直接修改JavaBean而不用到每個頁面上去尋找相同的代碼。同時也使得業務邏輯實現人員可以和界面開發人員分工合作。這種設計可以理解爲兩層架構（表現層、數據訪問+業務邏輯）。隨着編程技術的發展，人們發現不同的業務規則裏可能會用到相同的數據。如果按照原來的設計方式同樣存在許多重複的代碼在JavaBean裏。所以後來就將數據訪問和業務邏輯再次細分。形成了表現層+業務邏輯層+數據訪問層這種架構。當然，隨着技術的發展和系統複雜程序的增加，一個系統還可能存在其它的“層”，如：權限驗證層、對象緩存層等。
三層（多層）架構的出現，使得程序編寫的代碼得以重用，程序員之間可以更好地分工合作，程序架構更加清晰並易於維護。但三層（多層）架構並非適合於所有的項目開發。原先獲取一個數據只需直接從數據庫查詢出來即可。用到了三層（多層）架構後還得先通過業務邏輯層，然後數據訪問層纔可以得到。原來一個類或一段代碼就可以完成的操作變成了好幾個類協作才能完成。如果項目規模並不大，採用這樣的多層架構就像殺雞用牛刀一樣反而不順手了。所以，多層架構適用於需要協同開發且具有一定規模或業務較複雜的系統。同時由於分了多層，一個接口的變化可能會引起多層接口的修改。
MVC設計模式
MVC是一種非常經典的設計模式。它廣泛應用於各種語言和各種類型的應用中。MVC的思想是將“顯示”（View）、“數據”(Model)和“控制”(Control)分開。MVC (Model_view_controller)” 模型-視圖-控制器”。View部分負責向用戶展示數據和接收用戶輸入Control負責接收View傳來的輸入並執行相應的業務邏輯獲得執行結果，然後再調用View將結果向用戶呈現。Model是輸入和輸出的數據載體。MVC將顯示和控制分開，使得View的變化不會影響到Control的修改，同時同樣的數據可能會提交到不同的View進行顯示。
MVC多層架構
對於大多數朋友會認爲三層架構就是MVC的原因，我想可能是因爲MVC和三層架構都是分三個部分吧。多層架構的思想是低層爲上層服務，上層調用低層時根本不用關心具體實現（所以在多層架構中通常是通過接口進行調用，而非具體的實現對象）。MVC則是分工合作，相互協調。另外還有點需要說明一下:
MVC中的Model和三層架構中用到的Model在概念上並非同一對象(雖然在大多數情況下是同樣的類在擔當這個職責)。MVC中的Model是值對象(Value Object 簡稱VO)，其職責是封裝需要傳遞到View進行顯示的數據。三層架構中的Model是業務對象(Business Object簡稱BO)，其職責是在處理業務邏輯時進行數據傳遞。在有些複雜的系統中還有持久對象（Persistant Object簡稱PO）。
後記
不能將三層架構和MVC混爲一談，多層架構和MVC都是前人的經驗總結。好好利用多層架構和MVC可以開發出健壯、易於擴展的系統。而軟件開發人員必須深入理解這些設計模式的精髓方能靈活應用，否則將會深受其害，在開發中處處受制。
文章引用來自http://www.cnblogs.com/leo_gu/archive/2010/04/28/1723397.html