辰o(^o^)o的專欄[除非注釋原創(chuàng)，其它文章基本來源于網(wǎng)絡(luò)]

MVC如何工作

MVC是一個(gè)設(shè)計(jì)模式，它強(qiáng)制性的使應(yīng)用程序的輸入、處理和輸出分開。使用MVC應(yīng)用程序被分成三個(gè)核心部件：模型、視圖、控制器。它們各自處理自己的任務(wù)。

視圖
視圖是用戶看到并與之交互的界面。對(duì)老式的Web應(yīng)用程序來說，視圖就是由HTML元素組成的界面，在新式的Web應(yīng)用程序中，HTML依舊在視圖中扮演著重要的角色，但一些新的技術(shù)已層出不窮，它們包括Macromedia　Flash和象XHTML，XML/XSL，WML等一些標(biāo)識(shí)語言和Web　services.

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

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

控制器
控制器接受用戶的輸入并調(diào)用模型和視圖去完成用戶的需求。所以當(dāng)單擊Web頁面中的超鏈接和發(fā)送HTML表單時(shí)，控制器本身不輸出任何東西和做任何處理。它只是接收請(qǐng)求并決定調(diào)用哪個(gè)模型構(gòu)件去處理請(qǐng)求，然后用確定用哪個(gè)視圖來顯示模型處理返回的數(shù)據(jù)。

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

為什么要使用 MVC

大部分Web應(yīng)用程序都是用像ASP，PHP，或者CFML這樣的過程化語言來創(chuàng)建的。它們將像數(shù)據(jù)庫查詢語句這樣的數(shù)據(jù)層代碼和像HTML這樣的表示層代碼混在一起。經(jīng)驗(yàn)比較豐富的開發(fā)者會(huì)將數(shù)據(jù)從表示層分離開來，但這通常不是很容易做到的，它需要精心的計(jì)劃和不斷的嘗試。MVC從根本上強(qiáng)制性的將它們分開。盡管構(gòu)造MVC應(yīng)用程序需要一些額外的工作，但是它給我們帶來的好處是無庸質(zhì)疑的。

首先，最重要的一點(diǎn)是多個(gè)視圖能共享一個(gè)模型，正如我所提及的，現(xiàn)在需要用越來越多的方式來訪問你的應(yīng)用程序。對(duì)此，其中一個(gè)解決之道是使用MVC，無論你的用戶想要Flash界面或是 WAP 界面；用一個(gè)模型就能處理它們。由于你已經(jīng)將數(shù)據(jù)和業(yè)務(wù)規(guī)則從表示層分開，所以你可以最大化的重用你的代碼了。

由于模型返回的數(shù)據(jù)沒有進(jìn)行格式化，所以同樣的構(gòu)件能被不同界面使用。例如，很多數(shù)據(jù)可能用HTML來表示，但是它們也有可能要用Macromedia Flash和WAP來表示。模型也有狀態(tài)管理和數(shù)據(jù)持久性處理的功能，例如，基于會(huì)話的購物車和電子商務(wù)過程也能被Flash網(wǎng)站或者無線聯(lián)網(wǎng)的應(yīng)用程序所重用。

因?yàn)槟Ｐ褪亲园模⑶遗c控制器和視圖相分離，所以很容易改變你的應(yīng)用程序的數(shù)據(jù)層和業(yè)務(wù)規(guī)則。如果你想把你的數(shù)據(jù)庫從MySQL移植到Oracle，或者改變你的基于RDBMS數(shù)據(jù)源到LDAP，只需改變你的模型即可。一旦你正確的實(shí)現(xiàn)了模型，不管你的數(shù)據(jù)來自數(shù)據(jù)庫或是LDAP服務(wù)器，視圖將會(huì)正確的顯示它們。由于運(yùn)用MVC的應(yīng)用程序的三個(gè)部件是相互對(duì)立，改變其中一個(gè)不會(huì)影響其它兩個(gè)，所以依據(jù)這種設(shè)計(jì)思想你能構(gòu)造良好的松偶合的構(gòu)件。

對(duì)我來說，控制器的也提供了一個(gè)好處，就是可以使用控制器來聯(lián)接不同的模型和視圖去完成用戶的需求，這樣控制器可以為構(gòu)造應(yīng)用程序提供強(qiáng)有力的手段。給定一些可重用的模型和視圖，控制器可以根據(jù)用戶的需求選擇模型進(jìn)行處理，然后選擇視圖將處理結(jié)果顯示給用戶。

MVC的缺點(diǎn)
MVC的缺點(diǎn)是由于它沒有明確的定義，所以完全理解MVC并不是很容易。使用MVC需要精心的計(jì)劃，由于它的內(nèi)部原理比較復(fù)雜，所以需要花費(fèi)一些時(shí)間去思考。

你將不得不花費(fèi)相當(dāng)可觀的時(shí)間去考慮如何將MVC運(yùn)用到你的應(yīng)用程序，同時(shí)由于模型和視圖要嚴(yán)格的分離，這樣也給調(diào)試應(yīng)用程序到來了一定的困難。每個(gè)構(gòu)件在使用之前都需要經(jīng)過徹底的測(cè)試。一旦你的構(gòu)件經(jīng)過了測(cè)試，你就可以毫無顧忌的重用它們了。

根據(jù)我個(gè)人經(jīng)驗(yàn)，由于我們將一個(gè)應(yīng)用程序分成了三個(gè)部件，所以使用MVC同時(shí)也意味著你將要管理比以前更多的文件，這一點(diǎn)是顯而易見的。這樣好像我們的工作量增加了，但是請(qǐng)記住這比起它所能帶給我們的好處是不值一提。

MVC并不適合小型甚至中等規(guī)模的應(yīng)用程序，花費(fèi)大量時(shí)間將MVC應(yīng)用到規(guī)模并不是很大的應(yīng)用程序通常會(huì)得不償失。

MVC是一條創(chuàng)建軟件的好途徑
MVC設(shè)計(jì)模式是一個(gè)很好創(chuàng)建軟件的途徑，它所提倡的一些原則，像內(nèi)容和顯示互相分離可能比較好理解。但是如果你要隔離模型、視圖和控制器的構(gòu)件，你可能需要重新思考你的應(yīng)用程序，尤其是應(yīng)用程序的構(gòu)架方面。如果你肯接受MVC，并且有能力應(yīng)付它所帶來的額外的工作和復(fù)雜性，MVC將會(huì)使你的軟件在健壯性，代碼重用和結(jié)構(gòu)方面上一個(gè)新的臺(tái)階。


2解釋二  http://www.ask321.com/ask8/ask151598.htm
Model-View-Controller

a.       問題

如果開發(fā)一個(gè)企業(yè)級(jí)應(yīng)用，只需要一種客戶端的話，那么一切都非常容易解決。但真實(shí)情況是，我們必須面對(duì)運(yùn)行在各種設(shè)備上客戶端，象PDA，WAP瀏覽器以及運(yùn)行在桌面上的瀏覽器，我們不得不開發(fā)不同的應(yīng)用程序來處理來自不同客戶端的請(qǐng)求。數(shù)據(jù)訪問與現(xiàn)實(shí)將混淆在一起，可能會(huì)出現(xiàn)重復(fù)的數(shù)據(jù)訪問，導(dǎo)致整個(gè)開發(fā)周期沒有必要的延長(zhǎng)。



b.      建議的解決方法

Model-View-Controller (MVC) 開發(fā)模式被證明是有效的處理方法之一。它可以分離數(shù)據(jù)訪問和數(shù)據(jù)表現(xiàn)。你可以開發(fā)一個(gè)有伸縮性的，便于擴(kuò)展的控制器，來維護(hù)整個(gè)流程。如圖1所示為整個(gè)模式的結(jié)構(gòu)。MVC模式可以被映射到多層企業(yè)級(jí)的J2EE應(yīng)用上。

§         所有的企業(yè)數(shù)據(jù)以及商業(yè)邏輯可以作為模式。

§         視圖可以通過模式訪問數(shù)據(jù)，并根據(jù)客戶端的要求來顯示數(shù)據(jù)。視圖必須保證當(dāng)模式改變的時(shí)候，數(shù)據(jù)顯示也必須同時(shí)改變。

§         控制器用來結(jié)合模式和視圖，把客戶端來的請(qǐng)求轉(zhuǎn)換成模式能夠理解并執(zhí)行的請(qǐng)求，并且根據(jù)請(qǐng)求以及執(zhí)行結(jié)果來決定下一次顯示那一個(gè)視圖。

根據(jù)以上的邏輯，你可以象這樣建立一個(gè)應(yīng)用：

§         應(yīng)用的商業(yè)邏輯由MVC中的模式也就是EJB來表現(xiàn)。模式必須處理由控制器傳遞過來的對(duì)數(shù)據(jù)的訪問請(qǐng)求。

§         多個(gè)頁面組成了MVC中的視圖，這些視圖必須隨模式一起更新。

§         控制器是一系列接收用戶動(dòng)作的對(duì)象，他們把用戶的請(qǐng)求轉(zhuǎn)換成模式可理解的請(qǐng)求，并決定顯示那一個(gè)頁面當(dāng)模式處理完請(qǐng)求后。



圖 1

c.       要點(diǎn)

§         MVC結(jié)構(gòu)適用于那些多用戶的，可擴(kuò)展的，可維護(hù)的，具有很高交互性的系統(tǒng)。

§         MVC可以很好的表達(dá)用戶的交互和系統(tǒng)模式。

§         很方便的用多個(gè)視圖來顯示多套數(shù)據(jù)，是系統(tǒng)很方便的支持其他新的客戶端類型。

§         代碼重復(fù)達(dá)到最低。

§         由于分離了模式中的流控制和數(shù)據(jù)表現(xiàn)，可以分清開發(fā)者的責(zé)任，另外，也可以加快產(chǎn)品推向市場(chǎng)的時(shí)間

3 解釋三 http://www.chinaunix.net/bbsjh/14/1135.html

[轉(zhuǎn)帖]了解MVC架構(gòu)對(duì)于用Struts構(gòu)建的強(qiáng)大的Web應(yīng)用程序很重要

作者：cinc     發(fā)表時(shí)間：2002/12/03 08:48am

了解MVC架構(gòu)對(duì)于用Struts構(gòu)建的強(qiáng)大的Web應(yīng)用程序很重要 Struts是雅加達(dá)的一個(gè)項(xiàng)目，它提供了一個(gè)方法，可以在一個(gè)Web應(yīng)用程序中一起使用JavaServer   Pages（JSP）和servlets。它的目的是要解決完全由JSP或完全由servlet實(shí)現(xiàn)的應(yīng)用程序中的固有的問 題。 例如，servelts可以生成HTML頁面，但這么做很麻煩。另一方面，JSP可以很容易地用于傳統(tǒng)的 HTML頁面，但JSP頁面有其它的缺點(diǎn)。特別是，用JSP很難將內(nèi)容同內(nèi)容的顯示分開。 很容易將Java 代 碼同HTML混在一起，結(jié)果做出的東西又慢又難以維護(hù)。 然而，因?yàn)镴SP頁面容易使用，所以它們成為用Java構(gòu)建動(dòng)態(tài)的Web應(yīng)用程序的首選方法。除了容易編程 外，JSP頁面也被改進(jìn)了，所以現(xiàn)在它們克服了以前的某些局限性。JavaBeans和標(biāo)記庫只是在基礎(chǔ)的 JSP技術(shù)上的幾個(gè)改進(jìn)。這種類型的方法——JSP頁面單獨(dú)負(fù)責(zé)處理輸入的請(qǐng)求和回復(fù)客戶端——被稱為 Model 1架構(gòu)。 JavaServer Pages是servlets的特殊情況，所以兩者可以一起工作以彌補(bǔ)每個(gè)的不足，這似乎是合乎邏 輯的。這種類型的方法——你的Web架構(gòu)包含截然不同的但又互聯(lián)的處理數(shù)據(jù)模式、顯示代碼和程序控 制邏輯的JSP和servlet組件——被稱為Model 2架構(gòu)，或Model-View-Controller（MVC）架構(gòu)。 為了使用Struts架構(gòu)以及用JSP和servlets有效地編程，對(duì)MVC架構(gòu)的了解是很必要的。Model 1和MVC架 構(gòu)的主要不同就是請(qǐng)求是在哪里處理的。在Model 1架構(gòu)中，請(qǐng)求通過JSP接收，主要通過JSP處理。如 果JSP頁面需要來自任何其它應(yīng)用程序組件的服務(wù)，如一個(gè)數(shù)據(jù)庫，那么你就從頁面做適當(dāng)?shù)恼{(diào)用，把 數(shù)據(jù)返回到頁面，安排數(shù)據(jù)的格式并顯示出來。你可以把一些代碼放到一個(gè)或多個(gè)JavaBean中，但是這 么做本身沒有將邏輯同顯示完全分離。 MVC方法采用了JSP和servlet方法的最佳特性，使這兩種技術(shù)可以協(xié)同工作。明確的是，servlet是處理 層（控制器）。Servlet接收請(qǐng)求，很像Model 1架構(gòu)中JSP頁面所做的那樣，并確定如何滿足那些請(qǐng) 求。這就意味著，servlet控制輸入的請(qǐng)求和輸出的回應(yīng)。 商業(yè)邏輯體現(xiàn)了MVC架構(gòu)中的模式。商業(yè)邏輯代碼為頁面做處理。如果進(jìn)入servlet的請(qǐng)求是一個(gè)數(shù)據(jù)庫 查詢，servlet就將這個(gè)請(qǐng)求傳送到一個(gè)SQL調(diào)用或類似的數(shù)據(jù)庫代碼。如果請(qǐng)求是一個(gè)包括輸入信用卡 號(hào)的購買請(qǐng)求，那么事物處理代碼就接管了。在某種意義上，架構(gòu)的模式部分是讓應(yīng)用程序處于領(lǐng)先地 位的全部原因。 JSP頁面是顯示層（視圖），是用戶與應(yīng)用程序交互的地方。它提供輸入并顯示結(jié)果。頁面不應(yīng)該包括 任何腳本。它只是將數(shù)據(jù)傳送到servlet，并接收和顯示返回的數(shù)據(jù)。 該架構(gòu)的優(yōu)勢(shì)應(yīng)該是很明顯的。首先，它將計(jì)算和顯示清楚地分開了。結(jié)果很理想，在JSP頁面上沒有 出現(xiàn)處理過程，在servlet或商業(yè)邏輯中沒有數(shù)據(jù)格式。這種分離的另一個(gè)好處是Java程序員可以專注 于servlet代碼，HTML編寫者可以專注于JSP。 第二點(diǎn)，控制器servlet做頁面上的所有的決定。 在你 的頁面和邏輯中不會(huì)出現(xiàn)任何決策。這就提高了一個(gè)應(yīng)用程序的性能和可擴(kuò)展性，因?yàn)檎?qǐng)求可以被導(dǎo)向 架構(gòu)的不同的組件，甚至是不同的服務(wù)器。 運(yùn)用MVC架構(gòu) MVC架構(gòu)沒有必要成為用于所有Java應(yīng)用程序的最佳方法。 如你想象的那樣，它在準(zhǔn)備和編碼時(shí)往往很 復(fù)雜——這對(duì)簡(jiǎn)單的應(yīng)用程序來說是沒必要的。當(dāng)頁面導(dǎo)航相對(duì)來說比較簡(jiǎn)單和固定，而且應(yīng)用程序中 的頁面結(jié)構(gòu)可以由一個(gè)簡(jiǎn)單的目錄結(jié)構(gòu)管理時(shí), Model 1架構(gòu)仍然是最好的方法。這些應(yīng)用程序往往將 頁面流動(dòng)信息嵌入到頁面間的鏈接中。（JSP中出現(xiàn)forward()就告訴你，在該頁中有嵌入的邏輯，讓你 對(duì)顯示下一頁作出決定。）對(duì)于對(duì)流量或可擴(kuò)展性需求有限的靜態(tài)的應(yīng)用程序來說，標(biāo)準(zhǔn)的JSP模式仍 然是一個(gè)可行的選擇方案。 在一些情況下，你可能想把一個(gè)JSP應(yīng)用程序移植到MVC架構(gòu)中。例如，你可能開始時(shí)用的是Model 1， 簡(jiǎn)單的JSP架構(gòu)，隨著你的需求的增加，你會(huì)發(fā)現(xiàn)維護(hù)起來太復(fù)雜或太難了。如果你花很長(zhǎng)的時(shí)間對(duì)應(yīng) 用程序做相對(duì)來說較簡(jiǎn)單的修改，或者如果你經(jīng)常在你的代碼中發(fā)現(xiàn)bug，那么你的JSP導(dǎo)向的應(yīng)用程序 也許就不再是合適的方法了。 隨著應(yīng)用程序的發(fā)展和變化，頁面的流動(dòng)和商業(yè)邏輯也增加了。應(yīng)用程序變得難以維護(hù)，因?yàn)轫撁媪鲃?dòng) 邏輯跨多個(gè)頁面分布，而且商業(yè)邏輯可能開始存在于未計(jì)劃的地方。從Model 1轉(zhuǎn)到MVC的最佳時(shí)機(jī)就是 當(dāng)這些類型的維護(hù)問題出現(xiàn)的時(shí)候。 你也可以預(yù)先計(jì)劃將你的應(yīng)用程序從一個(gè)架構(gòu)移植到另一個(gè)架構(gòu)。當(dāng)你的應(yīng)用程序中的JSP頁面包含腳 本元素，定制標(biāo)記或JavaScript來執(zhí)行一個(gè)forward()操作時(shí)，你可能想調(diào)整你最初的設(shè)計(jì)，變成一種 用MVC架構(gòu)的設(shè)計(jì)。 Refactoring用在這兒是個(gè)不錯(cuò)的術(shù)語。它指的是以一種高度嚴(yán)謹(jǐn)?shù)姆绞街亟ùa結(jié)構(gòu)的一種技術(shù)。當(dāng) 你的代碼變得難以理解、修改和調(diào)試時(shí)，你通常就開始考慮調(diào)整了。你可以用幾種方式來調(diào)整代碼：你 可以簡(jiǎn)單地重新命名變量和方法，或者將部分代碼移植到不同類型的執(zhí)行模式中。更多的關(guān)于調(diào)整及其 技術(shù)方面的信息，請(qǐng)?jiān)L問Martin Fowler的網(wǎng)站www.refactoring.com 或者閱讀他寫的書   Refactoring: Improving the Design of Existing Code。 在許多情況下，一開始就選擇MVC架構(gòu)是很有意義的，例如你的應(yīng)用程序是為廣泛的企業(yè)應(yīng)用而設(shè)計(jì) 的，或者在幾年內(nèi)，你的應(yīng)用程序可能擴(kuò)展到一個(gè)相當(dāng)高的流量。 設(shè)計(jì)一個(gè)MVC架構(gòu)需要有深謀遠(yuǎn)慮。 大多數(shù)程序員發(fā)現(xiàn)寫邏輯腳本或JavaBeans，以及用HTML顯示很容易。當(dāng)你設(shè)計(jì)一個(gè)MVC架構(gòu)時(shí)，你必須 首先進(jìn)行一個(gè)完整的設(shè)計(jì)。這就意味著，分析需要處理的請(qǐng)求的類型，確定哪些組件（JavaBean、數(shù)據(jù) 庫或其它servlets）將處理這些請(qǐng)求，以及對(duì)那些請(qǐng)求的回應(yīng)是如何顯示給用戶的。 該設(shè)計(jì)的關(guān)鍵就 是請(qǐng)求和數(shù)據(jù)的流動(dòng)性。為MVC架構(gòu)設(shè)計(jì)應(yīng)用程序組件只是對(duì)你現(xiàn)在用JSP和servlets所做工作的擴(kuò)展。 面臨的挑戰(zhàn)就是構(gòu)建一個(gè)servlet，它接收請(qǐng)求并把那些請(qǐng)求分到應(yīng)用程序的不同的組件。將一個(gè)數(shù)據(jù) 庫請(qǐng)求傳送到一個(gè)數(shù)據(jù)庫，或?qū)⒁粋€(gè)處理請(qǐng)求傳送到一個(gè)JavaBean是很容易的，但是如果一個(gè)請(qǐng)求包含 這兩種元素，會(huì)怎樣呢？或者如果請(qǐng)求的性質(zhì)在一些處理出現(xiàn)前不能確定，又怎樣呢？ Struts 構(gòu)架 該挑戰(zhàn)使我們又回到Struts構(gòu)架。Struts提供了一個(gè)實(shí)現(xiàn)MVC架構(gòu)的高度自動(dòng)化的方式。它的結(jié)構(gòu)實(shí)現(xiàn) 了MVC，并包括一個(gè)控制器servlet、一組JSP頁面和應(yīng)用程序的商業(yè)邏輯。控制器將用戶請(qǐng)求打包，并 把它們導(dǎo)向架構(gòu)中的其他對(duì)象。 Struts構(gòu)架是圍繞一個(gè)ActionMapping 結(jié)構(gòu)的。控制器用 ActionMapping 把HTTP消息形式的用戶請(qǐng)求 轉(zhuǎn)換成應(yīng)用程序的動(dòng)作。ActionMapping指定請(qǐng)求的路徑、計(jì)劃處理請(qǐng)求的對(duì)象以及任何服務(wù)該請(qǐng)求需 要的其它信息。ActionMapping創(chuàng)建了一個(gè) Action 對(duì)象來處理請(qǐng)求。一旦Action對(duì)象完成了一個(gè)任 務(wù)，它就通過在一個(gè)JSP頁面上寫結(jié)果來直接回應(yīng)一個(gè)用戶請(qǐng)求，或者它可以讓一個(gè)應(yīng)用程序流動(dòng)到其 它地方做回應(yīng)。