幾種常用軟件架構(gòu)設(shè)計(jì)指引

1、幾種常用軟件架構(gòu)設(shè)計(jì)指南軟件架構(gòu)(software architecture)是一系歹U相關(guān)的抽象模式，用于指導(dǎo)大型 軟件系統(tǒng)各個(gè)方面的設(shè)計(jì)。軟件架構(gòu)是一個(gè)系統(tǒng)的草圖。軟件架構(gòu)描述的對(duì)象是 直接構(gòu)成系統(tǒng)的抽象組件。各個(gè)組件之間的連接則明確和相對(duì)細(xì)致地描述組件之 間的通訊。在實(shí)現(xiàn)階段，這些抽象組件被細(xì)化為實(shí)際的組件， 比如具體某個(gè)類或 者對(duì)象。在面向?qū)ο箢I(lǐng)域中，組件之間的連接通常用接口來(lái)實(shí)現(xiàn)。軟件體系結(jié)構(gòu)的定義雖然軟件體系結(jié)構(gòu)已經(jīng)在軟件工程領(lǐng)域中有著廣泛的應(yīng)用， 但迄今為止還沒(méi) 有一個(gè)被大家所公認(rèn)的定義。許多專家學(xué)者從不同角度和不同側(cè)面對(duì)軟件體系結(jié) 構(gòu)進(jìn)行了刻畫(huà)，較為典型的定義有：Dewayne

2、 Perry和Alex Wolf曾這樣定義：軟件體系結(jié)構(gòu)是具有一定形式的 結(jié)構(gòu)化元素，即構(gòu)件的集合，包括處理構(gòu)件、數(shù)據(jù)構(gòu)件和連接構(gòu)件。處理構(gòu)件負(fù) 責(zé)對(duì)數(shù)據(jù)進(jìn)行加工，數(shù)據(jù)構(gòu)件是被加工的信息，連接構(gòu)件把體系結(jié)構(gòu)的不同部分 組組合連接起來(lái)。這一定義注重區(qū)分處理構(gòu)件、數(shù)據(jù)構(gòu)件和連接構(gòu)件，這一方法 在其他的定義和方法中基本上得到保持。Mary Shaw和David Garlan認(rèn)為軟件體系結(jié)構(gòu)是軟件設(shè)計(jì)過(guò)程中的一個(gè)層次， 這一層次超越計(jì)算過(guò)程中的算法設(shè)計(jì)和數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)。體系結(jié)構(gòu)問(wèn)題包括總體組織和全局控制、通訊協(xié)議、同步、數(shù)據(jù)存取，給設(shè)計(jì)元素分配特定功能，設(shè)計(jì)元 素的組織，規(guī)模和性能，在各設(shè)計(jì)方案問(wèn)進(jìn)行選

3、擇等。軟件體系結(jié)構(gòu)處理算法與 數(shù)據(jù)結(jié)構(gòu)之上關(guān)于整體系統(tǒng)結(jié)構(gòu)設(shè)計(jì)和描述方面的一些問(wèn)題，如全局組織和全局控制結(jié)構(gòu)、關(guān)于通訊、同步與數(shù)據(jù)存取的協(xié)議，設(shè)計(jì)構(gòu)件功能定義，物理分布與 合成，設(shè)計(jì)方案的選擇、評(píng)估與實(shí)現(xiàn)等Kruchten指出，軟件體系結(jié)構(gòu)有四個(gè)角度，它們從不同方面對(duì)系統(tǒng)進(jìn)行描述：概念角度描述系統(tǒng)的主要構(gòu)件及它們之間的關(guān)系；模塊角度包含功能分解與層次 結(jié)構(gòu)；運(yùn)行角度描述了一個(gè)系統(tǒng)的動(dòng)態(tài)結(jié)構(gòu)； 代碼角度描述了各種代碼和庫(kù)函數(shù) 在開(kāi)發(fā)環(huán)境中的組織。Hayes Roth則認(rèn)為軟件體系結(jié)構(gòu)是一個(gè)抽象的系統(tǒng)規(guī)范，主要包括用其行為 來(lái)描述的功能構(gòu)件和構(gòu)件之間的相互連接、接口和關(guān)系。David Garlan

4、和Dewne Perry于1995年在IEEE軟件工程學(xué)報(bào)上乂采用如下 的定義：軟件體系結(jié)構(gòu)是一個(gè)程序/系統(tǒng)各構(gòu)件的結(jié)構(gòu)、 它們之間的相互關(guān)系以 及進(jìn)行設(shè)計(jì)的原則和隨時(shí)間進(jìn)化的指導(dǎo)方針。Barry Boehm和他的學(xué)生提出，一個(gè)軟件體系結(jié)構(gòu)包括一個(gè)軟件和系統(tǒng)構(gòu)件， 互聯(lián)及約束的集合；一個(gè)系統(tǒng)需求說(shuō)明的集合；一個(gè)基本原理用以說(shuō)明這一構(gòu)件， 互聯(lián)和約束能夠滿足系統(tǒng)需求。1997年，Bass, Ctements和Kazman在使用軟件體系結(jié)構(gòu)一書(shū)中給出如 下的定義：一個(gè)程序或計(jì)算機(jī)系統(tǒng)的軟件體系結(jié)構(gòu)包括一個(gè)或一組軟件構(gòu)件、軟件構(gòu)件的外部的可見(jiàn)特性及其相互關(guān)系。其中，軟件外部的可見(jiàn)特性是指軟件 構(gòu)件提

5、供的服務(wù)、性能、特性、錯(cuò)誤處理、共享資源使用等。軟件體系結(jié)構(gòu)建模研究軟件體系結(jié)構(gòu)的首要問(wèn)題是如何表示軟件體系結(jié)構(gòu)，即如何對(duì)軟件體系結(jié)構(gòu) 建模。根據(jù)建模的側(cè)重點(diǎn)的不同，可以將軟件體系結(jié)構(gòu)的模型分為5種：結(jié)構(gòu)模 型、框架模型、動(dòng)態(tài)模型、過(guò)程模型和功能模型。在這5個(gè)模型中，最常用的是 結(jié)構(gòu)模型和動(dòng)態(tài)模型。結(jié)構(gòu)模型這是一個(gè)最直觀、最普遍的建模方法。這種方法以體系結(jié)構(gòu)的構(gòu)件、連接件 和其他概念來(lái)刻畫(huà)結(jié)構(gòu)，并力圖通過(guò)結(jié)構(gòu)來(lái)反映系統(tǒng)的重要語(yǔ)義內(nèi)容， 包括系統(tǒng) 的配置、約束、隱含的假設(shè)條件、風(fēng)格、性質(zhì)。研究結(jié)構(gòu)模型的核心是體系結(jié)構(gòu) 描述語(yǔ)言。框架模型框架模型與結(jié)構(gòu)模型類似，但它不太側(cè)重描述結(jié)構(gòu)的細(xì)節(jié)而更側(cè)重于

6、整體的 結(jié)構(gòu)?？蚣苣Ｐ椭饕砸恍┨厥獾膯?wèn)題為目標(biāo)建立只針對(duì)和適應(yīng)該問(wèn)題的結(jié)構(gòu)。 動(dòng)態(tài)模型動(dòng)態(tài)模型是對(duì)結(jié)構(gòu)或框架模型的補(bǔ)充,研究系統(tǒng)的大顆粒的行為性質(zhì)。例 如，描述系統(tǒng)的重新配置或演化。動(dòng)態(tài)可能指系統(tǒng)總體結(jié)構(gòu)的配置、建立或拆除 通信通道或計(jì)算的過(guò)程。這類系統(tǒng)常是激勵(lì)型的。過(guò)程模型過(guò)程模型研究構(gòu)造系統(tǒng)的步驟和過(guò)程。因而結(jié)構(gòu)是遵循某些過(guò)程腳本的結(jié)果。功能模型該模型認(rèn)為體系結(jié)構(gòu)是由一組功能構(gòu)件按層次組成，下層向上層提供服務(wù)。它可以看作是一種特殊的框架模型。這5種模型各有所長(zhǎng)，也許將5種模型有機(jī)地統(tǒng)一在一起，形成一個(gè)完整的模型來(lái)刻畫(huà)軟件體系結(jié)構(gòu)更合適。例如，Kruchten在1995年提出了一個(gè)4+1的

7、視角 模型。4+1模型從5個(gè)不同的視角包括邏輯視角、過(guò)程視角、物理視角、開(kāi)發(fā) 視角和場(chǎng)景視角來(lái)描述軟件體系結(jié)構(gòu)。每一個(gè)視角只關(guān)心系統(tǒng)的一個(gè)側(cè)面, 視角結(jié)合在一起才能夠反映系統(tǒng)的軟件體系結(jié)構(gòu)的全部?jī)?nèi)容。靜態(tài)結(jié)構(gòu)圖 1 “4+1”視圖模型邏輯架構(gòu)邏輯架構(gòu)主要支持功能性需求一一即在為用戶提供服務(wù)方面系統(tǒng)所應(yīng)該提 供的功能。系統(tǒng)分解為一系列的關(guān)鍵抽象，（大多數(shù)）來(lái)自丁問(wèn)題域，表現(xiàn)為對(duì) 象或?qū)ο箢惖男问?。它們采用抽象、封裝和繼承的原理。分解并不僅僅是為了功 能分析，而且用來(lái)識(shí)別遍布系統(tǒng)各個(gè)部分的通用機(jī)制和設(shè)計(jì)元素。我們使用Rational/Booch方法來(lái)表示邏輯架構(gòu)，借助丁類圖和類模板的手段。類圖用來(lái)

8、顯 示一個(gè)類的集合和它們的邏輯關(guān)系：關(guān)聯(lián)、使用、組合、繼承等等。相似的類可 以劃分成類集合。類模板關(guān)注丁單個(gè)類，它們強(qiáng)調(diào)主要的類操作，并且識(shí)別關(guān)鍵 的對(duì)象特征。如果需要定義對(duì)象的內(nèi)部行為，則使用狀態(tài)轉(zhuǎn)換圖或狀態(tài)進(jìn)程視圖場(chǎng)最視圖動(dòng)凝吉構(gòu)邏輯現(xiàn)圖開(kāi)發(fā)視圖散用戶：由能需求開(kāi)岌人員：功能買現(xiàn)系統(tǒng)丁程師：系洗估撲,部客答系統(tǒng)集成人員：非.功能需求圖來(lái)完成。公共機(jī)制或服務(wù)可以在類功能(class utilities)中定義。對(duì)丁數(shù)據(jù)驅(qū)動(dòng)程度高的應(yīng)用程序，可以使用其他形式的邏輯視圖，例如E-R圖，來(lái)代替面向?qū)ο蟮姆椒?OO approach)。Connectors - Association.Contain

9、mentOUsqge InheritanceInnchtiQ圖 2 邏輯視圖表示符號(hào)開(kāi)發(fā)架構(gòu)開(kāi)發(fā)架構(gòu)關(guān)注軟件開(kāi)發(fā)環(huán)境下實(shí)際模塊的組織。軟件打包成小的程序塊(程 序庫(kù)或子系統(tǒng))，它們可以由一位或幾位開(kāi)發(fā)人員來(lái)開(kāi)發(fā)。子系統(tǒng)可以組織成分 層結(jié)構(gòu)，每個(gè)層為上一層提供良好定義的接口。系統(tǒng)的開(kāi)發(fā)架構(gòu)用模塊和子系統(tǒng) 圖來(lái)表達(dá)， 顯示了 ”輸出”和”輸入”關(guān)系。完整的開(kāi)發(fā)架構(gòu)只有當(dāng)所有軟件元素被 識(shí)別后才能加以描述。但是，可以列出控制開(kāi)發(fā)架構(gòu)的規(guī)則：分塊、分組和可見(jiàn) 性。ReferenceCompilatrOR dependency (IncludeLayerComponentsConnectorsCompo

10、nentsClassCig UlHItyParameterizedClaCtass cjtogoryMcduldSubsystem圖 3開(kāi)發(fā)視圖的標(biāo)識(shí)符號(hào)進(jìn)程架構(gòu)進(jìn)程架構(gòu)考慮一些非功能性的需求，如性能和可用性。它解決并發(fā)性、分布 性、系統(tǒng)完整性、容錯(cuò)性的問(wèn)題，以及邏輯視圖的主要抽象如何與進(jìn)程結(jié)構(gòu)相配 合在一起-即在哪個(gè)控制線程上，對(duì)象的操作被實(shí)際執(zhí)行。進(jìn)程架構(gòu)可以在幾種層次的抽象上進(jìn)行描述，每個(gè)層次針對(duì)不同的問(wèn)題。在最高的層次上，進(jìn)程架構(gòu) 可以視為一組獨(dú)立執(zhí)行的通信程序（叫作processes）的邏輯網(wǎng)絡(luò)，它們分布在 整個(gè)一組硬件資源上，這些資源通過(guò)LAN或者WAN連接起來(lái)。多個(gè)邏輯網(wǎng)絡(luò)可能同

11、時(shí)并存，共享相同的物理資源。例如，獨(dú)立的邏輯網(wǎng)絡(luò)可能用丁支持離 線系統(tǒng)與在線系統(tǒng)的分離，或者支持軟件的模擬版本和測(cè)試版本的共存。Connectors-U gp e-c Ifhd- R&m。悟PrcGdure CallY- Me&sage. bidlrecthnal Event broadestiIndicates前cyclical process圖 4進(jìn)程視圖的標(biāo)識(shí)符號(hào)物理架構(gòu)物理架構(gòu)主要關(guān)注系統(tǒng)非功能性的需求，如可用性、可靠性（容錯(cuò)性），性能（吞吐量）和可伸縮性。軟件在計(jì)算機(jī)網(wǎng)絡(luò)或處理節(jié)點(diǎn)上運(yùn)行，被識(shí)別的各種 元素（網(wǎng)絡(luò)、過(guò)程、任務(wù)和對(duì)象）,需要被映射至不同的節(jié)點(diǎn)；我們希望使

12、用不 同的物理配置：一些用丁開(kāi)發(fā)和測(cè)試，另外一些則用丁不同地點(diǎn)和不同客戶的部 署。因此軟件至節(jié)點(diǎn)的映射需要高度的靈活性及對(duì)源代碼產(chǎn)生最小的影響。Components5impiiTid ProcessP尊rh?di$processadornmentC on*inii|nicjlion IjrK-.Collin in mcalioniIFKVIprmarKiih圖 5物理視圖的標(biāo)識(shí)符號(hào)場(chǎng)景架構(gòu)四種視圖的元素通過(guò)數(shù)量比較少的一組重要場(chǎng)景 （更常見(jiàn)的是用例）進(jìn)行無(wú) 縫協(xié)同工作，我們?yōu)閳?chǎng)景描述相應(yīng)的腳本（對(duì)象之間和過(guò)程之間的交互序列）。在某種意義上場(chǎng)景是最重要的需求抽象，它們的設(shè)計(jì)使用對(duì)象場(chǎng)景圖和對(duì)象交

13、互 圖來(lái)表示。該視圖是其他視圖的冗余（因此+1）,但它起到了兩個(gè)作用：作為一項(xiàng)驅(qū)動(dòng)因素來(lái)發(fā)現(xiàn)架構(gòu)設(shè)計(jì)過(guò)程中的架構(gòu)元素。作為架構(gòu)設(shè)計(jì)結(jié)束后的一項(xiàng)驗(yàn)證和說(shuō)明功能， 既以視圖的角度來(lái)說(shuō)明乂作為 架構(gòu)原型測(cè)試的出發(fā)點(diǎn)。場(chǎng)景表示法與組件邏輯視圖非常相似（請(qǐng)對(duì)照?qǐng)D2）,但它使用過(guò)程視圖的連接符來(lái)表示對(duì)象之間的交互（請(qǐng)對(duì)照?qǐng)D4）,注意對(duì)象實(shí)例使用實(shí)線來(lái)表達(dá)。管道過(guò)濾器風(fēng)格軟件架構(gòu)在管道/過(guò)濾器風(fēng)格的軟件體系結(jié)構(gòu)中，每個(gè)構(gòu)件都有一組輸入和輸出，構(gòu) 件讀輸入的數(shù)據(jù)流，經(jīng)過(guò)內(nèi)部處理，然后產(chǎn)生輸出數(shù)據(jù)流。這個(gè)過(guò)程通常通過(guò)對(duì) 輸入流的變換及增量計(jì)算來(lái)完成，所以在輸入被完全消費(fèi)之前，輸出便產(chǎn)生了。因此，這里的構(gòu)件被稱為

14、過(guò)濾器，這種風(fēng)格的連接件就象是數(shù)據(jù)流傳輸?shù)墓艿溃?將一個(gè)過(guò)濾器的輸出傳到另一過(guò)濾器的輸入。 此風(fēng)格特別重要的過(guò)濾器必須是獨(dú) 立的實(shí)體，它不能與其它的過(guò)濾器共享數(shù)據(jù)，而且一個(gè)過(guò)濾器不知道它上游和下 游的標(biāo)識(shí)。一個(gè)管道/過(guò)濾器網(wǎng)絡(luò)輸出的正確性并不依賴丁過(guò)濾器進(jìn)行增量計(jì)算 過(guò)程的順序。CcmporipfittC+nr*oc lorsboPidwiLltta cijmiTiunicjlhcihL圖 6管道過(guò)濾器體系結(jié)構(gòu)圖 7 數(shù)字通信系統(tǒng)粗略模型管道/過(guò)濾器風(fēng)格的軟件體系結(jié)構(gòu)具有許多很好的特點(diǎn)：使得軟構(gòu)件具有良好的隱蔽性和高內(nèi)聚、低耦合的特點(diǎn)；允許設(shè)計(jì)者將整個(gè)系統(tǒng)的輸入/輸出行為看成是多個(gè)過(guò)濾器的行為

15、的簡(jiǎn)單合成；支持軟件重用。重要提供適合在兩個(gè)過(guò)濾器之間傳送的數(shù)據(jù)，任何兩個(gè)過(guò)濾 器都可被連接起來(lái)；系統(tǒng)維護(hù)和增強(qiáng)系統(tǒng)性能簡(jiǎn)單。新的過(guò)濾器可以添加到現(xiàn)有系統(tǒng)中來(lái)；舊的 可以被改進(jìn)的過(guò)濾器替換掉；允許對(duì)一些如吞吐量、死鎖等屆性的分析；支持并行執(zhí)行。每個(gè)過(guò)濾器是作為一個(gè)單獨(dú)的任務(wù)完成，因此可與其它任務(wù) 并行執(zhí)行。但是，這樣的系統(tǒng)也存在著若干不利因素。通常導(dǎo)致進(jìn)程成為批處理的結(jié)構(gòu)。 這是因?yàn)殡m然過(guò)濾器可增量式地處理數(shù)據(jù)， 但它們是獨(dú)立的，所以設(shè)計(jì)者必須將每個(gè)過(guò)濾器看成一個(gè)完整的從輸入到輸 出的轉(zhuǎn)換。不適合處理交互的應(yīng)用。當(dāng)需要增量地顯示改變時(shí)，這個(gè)問(wèn)題尤為嚴(yán)重。因?yàn)樵跀?shù)據(jù)傳輸上沒(méi)有通用的標(biāo)準(zhǔn)， 每個(gè)過(guò)

16、濾器都增加了解析和合成數(shù)據(jù)的 工作，這樣就導(dǎo)致了系統(tǒng)性能下降，并增加了編寫(xiě)過(guò)濾器的復(fù)雜性。層次風(fēng)格軟件架構(gòu)層次系統(tǒng)組織成一個(gè)層次結(jié)構(gòu)，每一層為上層服務(wù)，并作為下層客戶。在一 些層次系統(tǒng)中，除了一些精心挑選的輸出函數(shù)外，內(nèi)部的層只對(duì)相鄰的層可見(jiàn)。這樣的系統(tǒng)中構(gòu)件在一些層實(shí)現(xiàn)了虛擬機(jī) （在另一些層次系統(tǒng)中層是部分不透明 的）。連接件通過(guò)決定層問(wèn)如何交互的協(xié)議來(lái)定義，拓?fù)浼s束包括對(duì)相鄰層問(wèn)交互的約束。這種風(fēng)格支持基丁可增加抽象層的設(shè)計(jì)。 這樣，允許將一個(gè)復(fù)雜問(wèn)題 分解成一個(gè)增量步驟序列的實(shí)現(xiàn)。由丁每一層最多只影響兩層，同時(shí)只要給相鄰 層提供相同的接口，允許每層用不同的方法實(shí)現(xiàn)，同樣為軟件重用提供了強(qiáng)

17、大的 支持。圖8是層次系統(tǒng)風(fēng)格的示意圖。層次系統(tǒng)最廣泛的應(yīng)用是分層通信協(xié)議。在 這一應(yīng)用領(lǐng)域中，每一層提供一個(gè)抽象的功能，作為上層通信的基礎(chǔ)。較低的層 次定義低層的交互，最低層通常只定義硬件物理連接。圖 8 層次系統(tǒng)體系結(jié)構(gòu)層次系統(tǒng)有許多可取的屆性：支持基丁抽象程度遞增的系統(tǒng)設(shè)計(jì)， 使設(shè)計(jì)者可以把一個(gè)復(fù)雜系統(tǒng)按遞增的 步驟進(jìn)行分解；支持功能增強(qiáng)，因?yàn)槊恳粚又炼嗪拖噜彽纳舷聦咏换?，因此功能的改變最?影響相鄰的上下層；支持重用。只要提供的服務(wù)接口定義不變，同 ？組標(biāo)準(zhǔn)的接口，而允許各 種不同的實(shí)現(xiàn)方法。但是，層次系統(tǒng)也有其不足之處：并不是每個(gè)系統(tǒng)都可以很容易地劃分為分層的模式，甚至即使一個(gè)系統(tǒng)的

18、邏 輯結(jié)構(gòu)是層次化的，出丁對(duì)系統(tǒng)性能的考慮，系統(tǒng)設(shè)計(jì)師不得不把一些低級(jí) 或高級(jí)的功能綜合起來(lái)；彳艮難找到一個(gè)合適的、正確的層次抽象方法。三層應(yīng)用程序模式是我們最常用的模式之一。當(dāng)我們?cè)跍?zhǔn)備使用層來(lái)組織應(yīng)用程序的方式構(gòu)件一個(gè)業(yè)務(wù)解決方法，如何組織應(yīng)用程序以便重用業(yè)務(wù)邏輯、提 供部署靈活性并保留重要的資源連接，這就可以用三層應(yīng)用程序模式。圖 9 三層軟件架構(gòu)表現(xiàn)層：這一層負(fù)責(zé)與用戶的交互。提供服務(wù)，顯示信息（例如在windows或HTML頁(yè)面中，處理用戶請(qǐng)求（鼠標(biāo)點(diǎn)擊，鍵盤(pán)敲擊等），HTTP請(qǐng)求，命令行 調(diào)用。）業(yè)務(wù)層：邏輯，系統(tǒng)中真正的核心。業(yè)務(wù)層實(shí)現(xiàn)應(yīng)用程序的業(yè)務(wù)功能。數(shù)據(jù)訪問(wèn)層：與數(shù)據(jù)庫(kù)、消

19、息系統(tǒng)、事務(wù)管理器及其其他軟件包通信。表現(xiàn)層i !旺的艮務(wù)器是！ I應(yīng)用服劣嘉墾敵據(jù)層莒尸瑜HI沸曲服務(wù)器 -越朋服務(wù)器希集散據(jù)倉(cāng)也圖 10四層軟件架構(gòu)MVC模式MVC模式（Model-View-Controller）是軟件工程中的一種軟件架構(gòu)模式，把軟件系統(tǒng)分為三個(gè)基本部分：模型（Model）、視圖（View）和控制器（Controller）MVC模式最早由Trygve Reenskau昨1974年1提出， 是施樂(lè)帕羅奧多研 究中心 （Xerox PARC）在20世紀(jì)80年代為程序語(yǔ)言Smalltalk發(fā)明的一種軟件 設(shè)計(jì)模式。MVC模式的目的是實(shí)現(xiàn)一種動(dòng)態(tài)的程式設(shè)計(jì)， 使后續(xù)對(duì)程序的修改

20、和擴(kuò)展簡(jiǎn)化， 并且使程序某一部分的重復(fù)利用成為可能。除此之外，此模式通過(guò)對(duì)復(fù)雜度的簡(jiǎn)化，使程序結(jié)構(gòu)更加直觀。軟件系統(tǒng)通過(guò)對(duì)自身基本部份分離的同 時(shí)也賦予了各個(gè)基本部分應(yīng)有的功能。圖 11 MVC架構(gòu)模型（Model）“數(shù)據(jù)模型”（Model）用丁封裝與應(yīng)用程序的業(yè)務(wù)邏輯相關(guān)的數(shù)據(jù)以及對(duì)數(shù)據(jù)的處理方法?！澳Ｐ汀庇袑?duì)數(shù)據(jù)直接訪問(wèn)的權(quán)力，例如對(duì)數(shù) 據(jù)庫(kù)的訪問(wèn)?！澳Ｐ汀辈灰蕾嚒耙晥D”和“控制器”，也就是說(shuō)，模型不關(guān)心它會(huì) 被如何顯示或是如何被操作。但是模型中數(shù)據(jù)的變化一般會(huì)通過(guò)一種刷新機(jī)制被 公布。為了實(shí)現(xiàn)這種機(jī)制，那些用丁監(jiān)視此模型的視圖必須事先在此模型上注冊(cè)， 從而，視圖可以了解在數(shù)據(jù)模型上發(fā)生的

21、改變。視圖（View）視圖層能夠?qū)崿F(xiàn)數(shù)據(jù)有目的的顯示（理論上，這不是必需的）。 在視圖中一般沒(méi)有程序上的邏輯。為了實(shí)現(xiàn)視圖上的刷新功能，視圖需要訪問(wèn)它 監(jiān)視的數(shù)據(jù)模型（Model） ,因此應(yīng)該事先在被它監(jiān)視的數(shù)據(jù)那里注冊(cè)?？刂破鳎–ontroller）控制器起到不同層面間的組織作用，用丁控制應(yīng)用程 序的流程。它處理事件并作出響應(yīng)?！笆录卑ㄓ脩舻男袨楹蛿?shù)據(jù)模型上的改 變。MVC模式的優(yōu)點(diǎn)在最初的JSP網(wǎng)頁(yè)中，像數(shù)據(jù)庫(kù)查詢語(yǔ)句這樣的數(shù)據(jù)層代碼和像HTML這樣的表示層代碼混在一起。經(jīng)驗(yàn)比較豐富的開(kāi)發(fā)者會(huì)將數(shù)據(jù)從表示層分離開(kāi)來(lái),但這通常不是很容易做到的，它需要精心地計(jì)劃和不斷的嘗試強(qiáng)制性地將它們分開(kāi)。盡管構(gòu)造MVC應(yīng)用程序需要一些額外的工作，但是它帶 給我們的好處是毋庸置疑的。首先，多個(gè)視圖能共享一個(gè)模型。如今，同一個(gè)Web應(yīng)用程序會(huì)提供多種 用戶界面，例如用戶希望既能夠通過(guò)瀏覽器來(lái)收發(fā)電子郵件，還希望通過(guò)手機(jī)來(lái)訪問(wèn)電子郵箱，這就要求Web網(wǎng)站同時(shí)能提供Internet界面和WAP界面。在MVC設(shè)計(jì)模式中，模型響應(yīng)用戶請(qǐng)求并返回響應(yīng)數(shù)據(jù)，視圖負(fù)責(zé)格式化數(shù)據(jù)并 把它們呈現(xiàn)給用戶，業(yè)務(wù)邏輯和表示層分離，同一