模式在架構(gòu)設(shè)計(jì)中的應(yīng)用

1、架構(gòu)設(shè)計(jì)之模式應(yīng)用廣州市品高軟件開(kāi)發(fā)有限公司2022年9月12日目錄廣州市品高軟件開(kāi)發(fā)有限公司2常用架構(gòu)模式介紹架構(gòu)設(shè)計(jì)討論什么是架構(gòu)模式加構(gòu)設(shè)計(jì)內(nèi)容廣州市品高軟件開(kāi)發(fā)有限公司3軟件架構(gòu)的種類(lèi)廣州市品高軟件開(kāi)發(fā)有限公司4軟件系統(tǒng)的邏輯架構(gòu)圖邏輯架構(gòu)：軟件系統(tǒng)中元件之間的關(guān)系，比如用戶(hù)界面，數(shù)據(jù)庫(kù)，外部系統(tǒng)接口，商業(yè)邏輯元件，等等軟件架構(gòu)的種類(lèi)廣州市品高軟件開(kāi)發(fā)有限公司5物理架構(gòu)：軟件元件是怎樣放到硬件上的軟件系統(tǒng)的物理架構(gòu)圖軟件架構(gòu)的種類(lèi)系統(tǒng)架構(gòu)：系統(tǒng)的非功能性特征，如可擴(kuò)展性、可靠性、強(qiáng)壯性、靈活性、 性能等。系統(tǒng)架構(gòu)的設(shè)計(jì)要求架構(gòu)師具備軟件和硬件的功能和性能的過(guò)硬知識(shí)，是架 構(gòu)設(shè)計(jì)工作中最

2、為困難的工作。架構(gòu)的兩要素：元件劃分和設(shè)計(jì)決定。 元件劃分 一個(gè)軟件系統(tǒng)中的元件首先是邏輯元件。這些邏輯元件如何放到硬件上，以 及這些元件如何為整個(gè)系統(tǒng)的可擴(kuò)展性、可靠性、強(qiáng)壯性、靈活性、性能等 做出貢獻(xiàn)，是非常重要的信息。設(shè)計(jì)決定 進(jìn)行軟件設(shè)計(jì)需要做出的決定中，必然會(huì)包括邏輯結(jié)構(gòu)、物理結(jié)構(gòu)，以及它 們?nèi)绾斡绊懙较到y(tǒng)的所有非功能性特征。這些決定中會(huì)有很多是一旦作出， 就很難更改的。6架構(gòu)模式廣州市品高軟件開(kāi)發(fā)有限公司7架構(gòu)模式是一個(gè)系統(tǒng)的高層次策略，涉及到大尺度的組件以及整體性質(zhì)。架構(gòu)模式的好壞可以影響到總體布局和框架性結(jié)構(gòu)。 架構(gòu)模式是模式中的最高層次，描述軟件系統(tǒng)里的基本的結(jié)構(gòu)組織或綱要，

3、通常提供事先定義好的子系統(tǒng)，指定它們的責(zé)任，并給出把它們組織在一起的法則和指南。比如，用戶(hù)和文件系統(tǒng)安全策略模型，N-層結(jié)構(gòu)，組件對(duì)象服務(wù)等。一個(gè)架構(gòu)模式常常可以分解成很多個(gè)設(shè)計(jì)模式的聯(lián)合使用。有些作者把這種架構(gòu)模式叫做系統(tǒng)模式。架構(gòu)模式常常劃分成如下的幾種：1、From Mud to Structure型。幫助架構(gòu)師將系統(tǒng)合理劃分，避免形成一個(gè)對(duì)象的海洋。包括Layers（分層）模式、Blackboard（黑板）模式、Pipes/Filters（管道/過(guò) 濾器）模式等。2、分散系統(tǒng)型。為分散式系統(tǒng)提供完整的架構(gòu)設(shè)計(jì)，包括像Broker（中介）模式等。3、人機(jī)互動(dòng)（Interactive Sy

4、stems）型，支持包含有人機(jī)互動(dòng)介面的系統(tǒng)的架構(gòu)設(shè)計(jì)，例如： MVC（Model-View-Controller）模式、PAC（Presentation-Abstraction-Control）模式等。4、Adaptable Systems型，支持應(yīng)用系統(tǒng)適應(yīng)技術(shù)的變化、軟件功能需求的變化。如Reflection（反射）模式、Microkernel（微核）模式等。 分層模式廣州市品高軟件開(kāi)發(fā)有限公司8分層模式架構(gòu)設(shè)計(jì)一個(gè)主要的目的，就是把系統(tǒng)劃分成為很多“板塊”。劃分的方式通常有兩種，一種是橫向的劃分，一種是縱向劃分。橫向劃分將系統(tǒng)按照商業(yè)目的劃分。比如一個(gè)書(shū)店的管理系統(tǒng)可以劃分成為進(jìn)貨、銷(xiāo)

5、售、庫(kù)存管理、員工管理等等?？v向劃分則按照抽象層次的高低，將系統(tǒng)劃分成“層”，或叫Layer。比如一個(gè)公司的內(nèi)網(wǎng)管理系統(tǒng)通常可以劃分成為下面的幾個(gè)層次:。網(wǎng)頁(yè)，也就是用戶(hù)界面，負(fù)責(zé)顯示數(shù) 據(jù)、接受用戶(hù)輸入；。領(lǐng)域?qū)樱↗avaBean或者COM對(duì)象、 B2B服務(wù)等，封裝了必要的商業(yè)邏輯，負(fù) 責(zé)根據(jù)商業(yè)邏輯決定顯示什么數(shù)據(jù)、以及 如何根據(jù)用戶(hù)輸入的數(shù)據(jù)進(jìn)行計(jì)算；。數(shù)據(jù)庫(kù)，負(fù)責(zé)存儲(chǔ)數(shù)據(jù)，按照查詢(xún)要 求提供所存儲(chǔ)的數(shù)據(jù)。操作系統(tǒng)層，比如Windows NT或者 Solaris等。硬件層，比如SUN E450服務(wù)器等層次架構(gòu)模式 使用層架構(gòu)的好處： 1 。你使用層，但是不需要去了解層的實(shí) 現(xiàn)細(xì)節(jié)。

6、2 。 可以使用另一種技術(shù)來(lái)改變基礎(chǔ)的 層，而不會(huì)影響上面的層的應(yīng)用。 3。任何一層的變化不會(huì)影響到其他各層。4。 容易制定出層標(biāo)準(zhǔn)。 5。底下的層可以用來(lái)建立頂上的層的多 項(xiàng)服務(wù)。6。更容易容納新的技術(shù)和變化。層架構(gòu) 模式容許任何一層變更所使用的技術(shù) 層架構(gòu)的弱點(diǎn)： 1。層不可能封裝所有的功能，一旦有功 能變動(dòng)，勢(shì)必要波及所有的層。 2。效率降低。 3。層最難的問(wèn)題是要定義各個(gè)層的內(nèi)容， 以及要承擔(dān)的責(zé)任。 * 有時(shí)把Layer叫做Tier，但是Tier多帶有物理含義，不同的Tier往往位于不同的計(jì)算機(jī)上，由網(wǎng)絡(luò)連接起來(lái)，而Layer是純粹邏輯的概念，與物理劃分無(wú)關(guān)。9分層的方式 分層是為了

7、隔離各層的關(guān)注面 分層的標(biāo)準(zhǔn)是：將相似的事物分組在一起 將不同的事物分開(kāi) 分層的目標(biāo)在于隔離關(guān)注面： 不同層的元素與不同領(lǐng)域相關(guān)，例如，業(yè)務(wù)層關(guān) 注業(yè)務(wù)領(lǐng)域問(wèn)題、中間件層關(guān)注適配操作系統(tǒng)的底層差異等軟件自身問(wèn)題。 各層的元素屬于同一抽象級(jí)別，而不同抽象級(jí)別的特性不同，要求的處理方式也不一樣。 穩(wěn)定與變化的隔離。典型的三層結(jié)構(gòu) 如何使用都要看具體的情況才能夠決定，例子1：一個(gè)電子商務(wù)系統(tǒng)。要求能夠同時(shí)處理大量用戶(hù)的請(qǐng)求，用戶(hù)的范圍遍及全球，而且數(shù)字還在不斷增長(zhǎng)。但是業(yè)務(wù)邏輯很簡(jiǎn)單，無(wú)非是訂單的處理，以及和庫(kù)存系統(tǒng)的連接部分。這就要求1、表示層要友好，能夠適應(yīng)最廣泛的用戶(hù)，因此采用html技術(shù)；2

8、、支持分布式的處理，以勝任同時(shí)幾千的訪(fǎng)問(wèn)； 3、考慮未來(lái)的升級(jí)。 例子2：一個(gè)租借系統(tǒng)。系統(tǒng)的用戶(hù)少的多，但是業(yè)務(wù)邏輯很復(fù)雜。這就要求我們制作一個(gè)業(yè)務(wù)邏輯非常復(fù)雜的系統(tǒng)，還要給他們的用戶(hù)提供一個(gè)方便的輸入界面，wimp是一個(gè)不錯(cuò)的選擇。 例子3：簡(jiǎn)單的系統(tǒng)。非常簡(jiǎn)單，用戶(hù)少、邏輯少。但是也不是沒(méi)有問(wèn)題，簡(jiǎn)單意味著要快速交付，并且還要充分考慮日后的升級(jí)。因?yàn)樾枨笤诓粩嗟脑黾又小?1從本質(zhì)上講，層代表了一個(gè)應(yīng)用程序主要的功能。一般地，我們將應(yīng)用程序功能分為三個(gè)方面，對(duì)應(yīng)3層架構(gòu)模式。它們是數(shù)據(jù)層（data layer）、業(yè)務(wù)層（business layer）和表示層（presentation l

9、ayer）。數(shù)據(jù)層：包含數(shù)據(jù)存儲(chǔ)和與它交互的組件或服務(wù)。這些組件和服務(wù)在功能上和中間層相互獨(dú)立（盡管在物理上不必一定相互獨(dú)立-它們可以在同一臺(tái)服務(wù)器上）。業(yè)務(wù)層：包括一個(gè)或者多個(gè)組件服務(wù)，它們應(yīng)用商務(wù)規(guī)則、實(shí)現(xiàn)應(yīng)用程序邏輯并完成應(yīng)用程序運(yùn)行所需要的數(shù)據(jù)處理。作為這個(gè)過(guò)程的一部分，中間層負(fù)責(zé)處理來(lái)自數(shù)據(jù)存儲(chǔ)或者發(fā)送給數(shù)據(jù)存儲(chǔ)的數(shù)據(jù)。表示層：從中間層獲得信息并顯示給用戶(hù)。該層同時(shí)也負(fù)責(zé)和用戶(hù)進(jìn)行交互，比較返回的信息并將信息回送給中間層進(jìn)行處理。Brown model ：表示層（Presentation），控制/中介層（Controller/Mediator），領(lǐng)域?qū)樱―omain）, 數(shù)據(jù)映射層（

10、Data Mapping）, 數(shù)據(jù)源層（Data Source）。Brown ISA表示層和領(lǐng)域?qū)拥闹薪閷樱槍?duì)一些非可視的控件。例如為特定的表示層組織信息格式，在不 同的窗口間導(dǎo)航，處理交易邊界，提供Server的facade接口。這樣做，一些領(lǐng)域邏輯被放到這個(gè)層里會(huì)影響到其 它的表示層。把行為分配給表示層是有好處的可以簡(jiǎn)化問(wèn)題，但表示層模型會(huì)比較復(fù)雜，所以，把這些行為放到非可視化的對(duì)象中，并提取出一個(gè)表示-領(lǐng)域中介層是值得的。 領(lǐng)域?qū)雍突A(chǔ)架構(gòu)層之間的中介層屬于Database Mapper模式，是三種領(lǐng)域?qū)拥綌?shù)據(jù)連接的辦法之一。和表示-領(lǐng)域中介層一樣，有時(shí)候有用，但不是所有時(shí)候都有用。

11、J2EE的架構(gòu)客戶(hù)層（Client），表示層（Presentation），業(yè)務(wù)層（Business ），整合層（Integration），資源層（Resource）。J2EE核心 ISA 客戶(hù)層 運(yùn)行在客戶(hù)機(jī)上的表示層 ，表示層 運(yùn)行在服務(wù)器上的表示層 ，業(yè)務(wù)層 領(lǐng)域?qū)?，整合層 基礎(chǔ)架構(gòu)層 ，資源層 基礎(chǔ)架構(gòu)層通信的外部數(shù)據(jù) 。微軟的DNA架構(gòu)定義了三個(gè)層：表示層（presentation），業(yè)務(wù)層（business），和數(shù)據(jù)存儲(chǔ)層（data access），但是在數(shù)據(jù)的傳遞方式上還有很大的不同。 在微軟的DNA中，各層的操作都基于數(shù)據(jù)存儲(chǔ)層傳出的SQL查詢(xún)結(jié)果集。這樣的話(huà)，實(shí)際上是增加了表

12、示層和業(yè)務(wù)層同數(shù)據(jù)存儲(chǔ)層之間的耦合度。DNA的記錄集在層之間的動(dòng)作類(lèi)似于Data Transfer Object。 更多的層模式 12OCRM系統(tǒng)總體功能架構(gòu)（第一級(jí)）13 系統(tǒng)劃分為“界面展現(xiàn)層”、“核心業(yè)務(wù)層”、“共享功能層”、“基礎(chǔ)服務(wù)層”、“企業(yè)數(shù)據(jù)層”五個(gè)層次。 根據(jù)依賴(lài)倒置原則，各層次之間之能向下引用，即上層模塊只能調(diào)用下層模塊的接口，下層模塊不能調(diào)用上層模塊接口，同層模塊之間不能相互引用。基礎(chǔ)服務(wù)ISO七層協(xié)議廣州市品高軟件開(kāi)發(fā)有限公司14ISO Open Systems Interconnect 7-layer model目錄廣州市品高軟件開(kāi)發(fā)有限公司15管道和過(guò)濾器體系架構(gòu)模

13、式管道和過(guò)濾器體系架構(gòu)模式它是為處理數(shù)據(jù)流的系統(tǒng)提供的一種模式，是由過(guò)濾器和管道組成的。每個(gè)處理步驟都被封裝在一個(gè)過(guò)濾器組件中，數(shù)據(jù)通過(guò)相鄰過(guò)濾器之間的管道進(jìn)行傳輸。每個(gè) 過(guò)濾器可以單獨(dú)修改，功能單一，并且它們之間的順序可以進(jìn)行配置。系統(tǒng)的設(shè)計(jì)尤其是處理步驟的內(nèi)部連接，必須考慮以下因素：未來(lái)系統(tǒng)的升級(jí)通過(guò)替換某些處理步驟，或重組步驟、不同的語(yǔ)境中小的處理步驟要比大的組件更易于重用、不相連的處理步驟不可共享信息、對(duì)不同的輸入數(shù)據(jù)源和可以用多種方式輸出或存放最終結(jié)果。這種模式的特性是：。過(guò)濾器是獨(dú)立運(yùn)行的部件，除了輸入和輸出外，每個(gè)過(guò)濾器不受任何其他過(guò)濾器運(yùn)行的影響。在設(shè)計(jì)上，過(guò)濾器之間不共享任何

14、狀態(tài)信息。獨(dú)立性還表現(xiàn)在它對(duì)其處理的上游和下游連接的過(guò)濾器是“無(wú)知”的。它的設(shè)計(jì)和使用不對(duì)與其連接的任何過(guò)濾器施加限制，唯一關(guān)心的是其輸入數(shù)據(jù)的，然后進(jìn)行加工處理，最后產(chǎn)生數(shù)據(jù)輸出。在使用管道和過(guò)濾器模式時(shí)，一般會(huì)使用的相關(guān)設(shè)計(jì)模式有：職責(zé)鏈模式(Chain Of Responsibility)、命令模式(Command)和裝飾模式(Decorator)。16管道和過(guò)濾器體系架構(gòu)模式的實(shí)施把系統(tǒng)任務(wù)分成一系列處理階段根據(jù)管道和過(guò)濾器的設(shè)計(jì)方案，必須把系統(tǒng)處理的任務(wù)分割成相應(yīng)獨(dú)立的任務(wù)，如日志，數(shù)據(jù)轉(zhuǎn)化，安全認(rèn)證等。這樣每個(gè)階段僅依賴(lài)其前一階段的輸出。通過(guò) 數(shù)據(jù)流將所有階段相連起來(lái)。并且你可以進(jìn)

15、行替換每個(gè)步驟，或者可以調(diào)整它們之間的順序，以產(chǎn)生新的結(jié)果。如將編碼轉(zhuǎn)化Filter和安 全Filter，分成兩個(gè)獨(dú)立的處理階段。定義沿每個(gè)管道傳輸?shù)臄?shù)據(jù)格式每個(gè)過(guò)濾器以定義一個(gè)統(tǒng)一格式以獲得最大的靈活性，因?yàn)樗惯^(guò)濾器的重組變得容易。如：每個(gè)過(guò)濾器的方法是doFilter(ServletRequest request， ServletResponse response， FilterChain filterChain)它們的參數(shù)是必須相同的。決定如何實(shí)現(xiàn)每個(gè)管道連接過(guò)濾器的連接是通過(guò)前一個(gè)過(guò)濾器主動(dòng)的調(diào)用filterChain.doFilter(request， response)來(lái)實(shí)現(xiàn)轉(zhuǎn)向

16、下一個(gè)過(guò)濾器。設(shè)計(jì)和實(shí)現(xiàn)過(guò)濾器設(shè)計(jì)每個(gè)過(guò)濾器具有獨(dú)立的功能，如編碼轉(zhuǎn)化，安全校驗(yàn)，等功能，并且每個(gè)過(guò)濾器都應(yīng)該在實(shí)現(xiàn)javax.servlet.Filter接口。建立處理流水線(xiàn)過(guò)濾器的部署是在Web.xml中進(jìn)行配置，描述過(guò)濾器的實(shí)現(xiàn)類(lèi)以及它們的map關(guān)系，來(lái)確定它們的順序。17優(yōu)點(diǎn)與缺點(diǎn)優(yōu)點(diǎn)：結(jié)構(gòu)簡(jiǎn)單：系統(tǒng)的行為是所有過(guò)濾器行為的簡(jiǎn)單復(fù)合。系統(tǒng)易于維護(hù)和增強(qiáng)：增加新過(guò)濾器，替換舊過(guò)濾器。支持復(fù)用：過(guò)濾器只同其輸入、輸出端口的數(shù)據(jù)相關(guān)。各過(guò)濾器可以并發(fā)運(yùn)行。缺點(diǎn)：容易導(dǎo)致批處理方式：每個(gè)過(guò)濾器從輸入數(shù)據(jù)到輸出數(shù)據(jù)的轉(zhuǎn)換是一個(gè)整體。轉(zhuǎn)換通常不適合交互式的應(yīng)用。有時(shí)必須維護(hù)兩個(gè)分離而又相關(guān)的流之間

17、的對(duì)應(yīng)關(guān)系。同實(shí)現(xiàn)有關(guān)，過(guò)濾器之間的數(shù)據(jù)傳輸率較低，而且每個(gè)過(guò)濾器都要作類(lèi)似的數(shù)據(jù)打包和解包的工作。示例：ETL調(diào)度中心廣州市品高軟件開(kāi)發(fā)有限公司19 數(shù)據(jù)中心的數(shù)據(jù)處理調(diào)度都同ETL的調(diào)度中心提供，通過(guò)配置ETL任務(wù)調(diào)度和作業(yè)調(diào)度流程來(lái)進(jìn)行數(shù)據(jù)處理計(jì)劃。示例：企業(yè)服務(wù)總線(xiàn)設(shè)計(jì)廣州市品高軟件開(kāi)發(fā)有限公司20管道和過(guò)濾器體系架構(gòu)模式的應(yīng)用實(shí)例2、AXISAixs是apache開(kāi)源的webservice實(shí)現(xiàn)服務(wù)器。xis處理 Message，首先截獲客戶(hù)端的請(qǐng)求，然后轉(zhuǎn)發(fā)到真正的實(shí)現(xiàn)業(yè)務(wù)邏輯上處理客戶(hù)端的請(qǐng)求，在這之前經(jīng)過(guò)一系列的handler處理。Handler就是過(guò)濾器，處理順序時(shí)要考慮部署描

18、述符(deployment configuration )是在客戶(hù)端還是服務(wù)器端。Handler處理的對(duì)象是MessageContext，由3個(gè)重要的部分組成：request Message、response message和屬性。在服務(wù)器端，有一個(gè)Transport Listener，它監(jiān)聽(tīng)客戶(hù)端的請(qǐng)求。通過(guò)多種協(xié)議，在客戶(hù)有請(qǐng)求時(shí)將按照協(xié)議的規(guī)范把數(shù)據(jù)解析生成一個(gè)Message對(duì)象，然后把它設(shè)置到MessageContext，然后調(diào) 用一系列的Handler進(jìn)行處理，其結(jié)構(gòu)圖如右所示。21Client/Server模式Client/Server模式廣州市品高軟件開(kāi)發(fā)有限公司22客戶(hù)/服務(wù)器

19、（Client/Server）系統(tǒng)分為客戶(hù)和服務(wù)器，服務(wù)器一直處于偵聽(tīng)的狀態(tài)，客戶(hù)主動(dòng)連接服務(wù)器，每個(gè)服務(wù)器可以為多個(gè)客戶(hù)服務(wù)。優(yōu)缺點(diǎn)優(yōu)點(diǎn)：結(jié)構(gòu)簡(jiǎn)單，系統(tǒng)中不同類(lèi)型的任務(wù)分別由客戶(hù)和服務(wù)器承擔(dān)，有利于發(fā)揮不同機(jī)器平臺(tái)的優(yōu)勢(shì)；支持分布式、并發(fā)環(huán)境，特別是當(dāng)客戶(hù)和服務(wù)器之間的關(guān)系是多對(duì)多時(shí)，可以有效地提高資源的利用率和共享程度；服務(wù)器集中管理資源，有利于權(quán)限控制和系統(tǒng)安全。缺點(diǎn)：在大多數(shù)client-server風(fēng)格的系統(tǒng)中，構(gòu)件之間的連接通過(guò)（遠(yuǎn)程）過(guò)程調(diào)用，接近于代碼一級(jí)，表達(dá)能力較弱。示例：即時(shí)通信廣州市品高軟件開(kāi)發(fā)有限公司25MVC模式廣州市品高軟件開(kāi)發(fā)有限公司26MVC模式模型-視圖-控

20、制器（MVC）當(dāng)應(yīng)用程序的用戶(hù)界面非常復(fù)雜，且關(guān)于用戶(hù)界面的需求很容易變化時(shí)，我們可以把交互類(lèi)型的軟件抽象成模型、視圖和控制器這三類(lèi)組件單元，這種抽象可以很好地分離用戶(hù)界面和業(yè)務(wù)邏輯，適應(yīng)變化的需求。大多數(shù)現(xiàn)代交互軟件都在一定程度上符合這一架構(gòu)模型的特點(diǎn)。MVC模式最吸引人之處在于它迫使用戶(hù)必須抽象自己的代碼，把項(xiàng)目分為表示、邏輯和控制三部分,每部分間的關(guān)聯(lián)較小。以MVC模式構(gòu)造軟件,可以使得軟件結(jié)構(gòu)靈活、重用性好、擴(kuò)展性佳。模型視圖控制器交互的示意圖模型：視圖：控制器:模型：模型表示應(yīng)用的數(shù)據(jù)及操作這些數(shù)據(jù)的邏輯方法。任何和整個(gè)應(yīng)用有關(guān)的持久性數(shù)據(jù)都應(yīng)該放在模型中。對(duì)于模型,它所提供的API

21、不能只針對(duì)某一個(gè)專(zhuān)門(mén)的視圖或控制器,應(yīng)該更一般化以適應(yīng)不同客戶(hù)的需求。視圖：視圖將模型的當(dāng)前狀態(tài)展示給用戶(hù),具體的顯示方法由視圖負(fù)責(zé),因此一個(gè)模型可以適用多個(gè)不同的視圖。在模型狀態(tài)改變后,通過(guò)模型和視圖之間的協(xié)議,視圖得知這種改變并修改自己的顯示。對(duì)于用戶(hù)的輸入,視圖將它們交給控制器處理?？刂破?控制器負(fù)責(zé)交互和將用戶(hù)輸入的數(shù)據(jù)導(dǎo)入模型,它還利用用戶(hù)的輸入將應(yīng)用轉(zhuǎn)向其他視圖。一些非持久的臨時(shí)數(shù)據(jù)也應(yīng)該在視圖中存取。采用MVC的好處顯示、邏輯和數(shù)據(jù)分開(kāi),這樣一方面的改變不會(huì)影響另一方面。更新視圖：如原來(lái)用的是CLI (Command Line Interface)的,后來(lái)要改成GUI,只要了解原

22、來(lái)的模型和控制器的接口,然后構(gòu)造GUI,把它按過(guò)去的協(xié)議和模型關(guān)聯(lián)起來(lái)就可以了,這樣做增加了組件的重用性和靈活性。復(fù)用視圖：假設(shè)針對(duì)某個(gè)模型數(shù)據(jù)開(kāi)發(fā)了一套View,那么在其他訪(fǎng)問(wèn)該模型數(shù)據(jù)的地方,完全可以再次使用該套件或?qū)F(xiàn)在的View組合成一個(gè)復(fù)合視圖。每個(gè)單視圖有自己和模型的連接協(xié)議和自己的響應(yīng)控制器,這樣開(kāi)發(fā)就僅僅變成了簡(jiǎn)單的組合。更新控制器：以在不更改視圖顯示的情況下,更改控制器,以達(dá)到更改視圖與用戶(hù)交互的響應(yīng)模式的目的。廣州市品高軟件開(kāi)發(fā)有限公司31基于MVC設(shè)計(jì)模式的WEB應(yīng)用框架將普通三層架構(gòu)的表示層細(xì)分成視圖格式層和表 示控制邏輯層。表示層涉及基于“瘦客戶(hù)”技術(shù)的用戶(hù)視圖格式服務(wù)器端表示和相應(yīng)的交互式控制邏輯。視圖格式層，只保留了構(gòu)建客戶(hù)端用戶(hù)視圖必要的顯示格式 和事件觸發(fā)；而在表示控制邏輯層則如名稱(chēng)所描述的那樣，實(shí)現(xiàn)了人機(jī)交互所需控制邏輯和部分業(yè)務(wù)會(huì)話(huà)邏輯，再加上貫穿所有系統(tǒng)邏輯層的業(yè)務(wù)實(shí)體，則構(gòu)成了以 MVC模式為核心的表示