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

cinc

了解MVC架構(gòu)對于用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é)處理輸入的請求和回復(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有效地編程，對MVC架構(gòu)的了解是很必要的。Model 1和MVC架
構(gòu)的主要不同就是請求是在哪里處理的。在Model 1架構(gòu)中，請求通過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接收請求，很像Model 1架構(gòu)中JSP頁面所做的那樣，并確定如何滿足那些請
求。這就意味著，servlet控制輸入的請求和輸出的回應(yīng)。

商業(yè)邏輯體現(xiàn)了MVC架構(gòu)中的模式。商業(yè)邏輯代碼為頁面做處理。如果進(jìn)入servlet的請求是一個(gè)數(shù)據(jù)庫
查詢，servlet就將這個(gè)請求傳送到一個(gè)SQL調(diào)用或類似的數(shù)據(jù)庫代碼。如果請求是一個(gè)包括輸入信用卡
號(hào)的購買請求，那么事物處理代碼就接管了。在某種意義上，架構(gòu)的模式部分是讓應(yīng)用程序處于領(lǐng)先地
位的全部原因。

JSP頁面是顯示層（視圖），是用戶與應(yīng)用程序交互的地方。它提供輸入并顯示結(jié)果。頁面不應(yīng)該包括
任何腳本。它只是將數(shù)據(jù)傳送到servlet，并接收和顯示返回的數(shù)據(jù)。

該架構(gòu)的優(yōu)勢應(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)檎埱罂梢员粚?dǎo)向
架構(gòu)的不同的組件，甚至是不同的服務(wù)器。


運(yùn)用MVC架構(gòu)

MVC架構(gòu)沒有必要成為用于所有Java應(yīng)用程序的最佳方法。 如你想象的那樣，它在準(zhǔn)備和編碼時(shí)往往很
復(fù)雜——這對簡單的應(yīng)用程序來說是沒必要的。當(dāng)頁面導(dǎo)航相對來說比較簡單和固定，而且應(yīng)用程序中
的頁面結(jié)構(gòu)可以由一個(gè)簡單的目錄結(jié)構(gòu)管理時(shí), Model 1架構(gòu)仍然是最好的方法。這些應(yīng)用程序往往將
頁面流動(dòng)信息嵌入到頁面間的鏈接中。（JSP中出現(xiàn)forward()就告訴你，在該頁中有嵌入的邏輯，讓你
對顯示下一頁作出決定。）對于對流量或可擴(kuò)展性需求有限的靜態(tài)的應(yīng)用程序來說，標(biāo)準(zhǔn)的JSP模式仍
然是一個(gè)可行的選擇方案。

在一些情況下，你可能想把一個(gè)JSP應(yīng)用程序移植到MVC架構(gòu)中。例如，你可能開始時(shí)用的是Model 1，
簡單的JSP架構(gòu)，隨著你的需求的增加，你會(huì)發(fā)現(xiàn)維護(hù)起來太復(fù)雜或太難了。如果你花很長的時(shí)間對應(yīng)
用程序做相對來說較簡單的修改，或者如果你經(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ù)姆绞街亟ù�碼結(jié)構(gòu)的一種技術(shù)。當(dāng)
你的代碼變得難以理解、修改和調(diào)試時(shí)，你通常就開始考慮調(diào)整了。你可以用幾種方式來調(diào)整代碼：你
可以簡單地重新命名變量和方法，或者將部分代碼移植到不同類型的執(zhí)行模式中。更多的關(guān)于調(diào)整及其
技術(shù)方面的信息，請?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ì)。這就意味著，分析需要處理的請求的類型，確定哪些組件（JavaBean、數(shù)據(jù)
庫或其它servlets）將處理這些請求，以及對那些請求的回應(yīng)是如何顯示給用戶的。 該設(shè)計(jì)的關(guān)鍵就
是請求和數(shù)據(jù)的流動(dòng)性。為MVC架構(gòu)設(shè)計(jì)應(yīng)用程序組件只是對你現(xiàn)在用JSP和servlets所做工作的擴(kuò)展。
面臨的挑戰(zhàn)就是構(gòu)建一個(gè)servlet，它接收請求并把那些請求分到應(yīng)用程序的不同的組件。將一個(gè)數(shù)據(jù)
庫請求傳送到一個(gè)數(shù)據(jù)庫，或?qū)⒁粋�(gè)處理請求傳送到一個(gè)JavaBean是很容易的，但是如果一個(gè)請求包含
這兩種元素，會(huì)怎樣呢？或者如果請求的性質(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è)邏輯�？刂破鲗⒂脩粽埱蟠虬�，并
把它們導(dǎo)向架構(gòu)中的其他對象。

Struts構(gòu)架是圍繞一個(gè)ActionMapping 結(jié)構(gòu)的�？刂破饔� ActionMapping 把HTTP消息形式的用戶請求
轉(zhuǎn)換成應(yīng)用程序的動(dòng)作。ActionMapping指定請求的路徑、計(jì)劃處理請求的對象以及任何服務(wù)該請求需
要的其它信息。ActionMapping創(chuàng)建了一個(gè) Action 對象來處理請求。一旦Action對象完成了一個(gè)任
務(wù)，它就通過在一個(gè)JSP頁面上寫結(jié)果來直接回應(yīng)一個(gè)用戶請求，或者它可以讓一個(gè)應(yīng)用程序流動(dòng)到其
它地方做回應(yīng)。