模式在架構(gòu)設(shè)計中的應(yīng)用_第1頁
模式在架構(gòu)設(shè)計中的應(yīng)用_第2頁
模式在架構(gòu)設(shè)計中的應(yīng)用_第3頁
模式在架構(gòu)設(shè)計中的應(yīng)用_第4頁
模式在架構(gòu)設(shè)計中的應(yīng)用_第5頁
已閱讀5頁,還剩37頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認(rèn)領(lǐng)

文檔簡介

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

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

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

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

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

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

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

8、、支持分布式的處理,以勝任同時幾千的訪問; 3、考慮未來的升級。 例子2:一個租借系統(tǒng)。系統(tǒng)的用戶少的多,但是業(yè)務(wù)邏輯很復(fù)雜。這就要求我們制作一個業(yè)務(wù)邏輯非常復(fù)雜的系統(tǒng),還要給他們的用戶提供一個方便的輸入界面,wimp是一個不錯的選擇。 例子3:簡單的系統(tǒng)。非常簡單,用戶少、邏輯少。但是也不是沒有問題,簡單意味著要快速交付,并且還要充分考慮日后的升級。因為需求在不斷的增加之中。11從本質(zhì)上講,層代表了一個應(yīng)用程序主要的功能。一般地,我們將應(yīng)用程序功能分為三個方面,對應(yīng)3層架構(gòu)模式。它們是數(shù)據(jù)層(data layer)、業(yè)務(wù)層(business layer)和表示層(presentation l

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

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

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

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

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

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

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

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

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

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

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

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

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

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

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論