【正文】 使用，所以結(jié)構(gòu)很好，所以擴展性也很好，而且它是不斷升級的，使用框架的開發(fā)者可以直接享受別人升級代碼帶來的好處。 ? 框架一般處在低層應(yīng)用平臺（如 J2EE）和高層業(yè)務(wù)邏輯之間的中間層。 187 常見的框架 ? 常見的 JAVA框架 ? 常見的 .Net框架 ? 其它基于 C++的框架 188 常見的 JAVA框架 ? EJB ? WAF ? Struts ? Turbine ? COCOON ? ECHO ? JATO ? TCF ? Spring ? Hibernate ? IBatis ? JSF 189 .NET 框架 ? .NET 框架是創(chuàng)建、部署和運行 Web 服務(wù)及其他應(yīng)用程序的一個環(huán)境。它包括三個主要部分：公共語言運行時、框架類和 。 ? .NET 框架對 Web 站點的支持： ? 在編寫 Windows 軟件（使用 ATL/COM、 MFC、 VB或標(biāo)準(zhǔn) Win32）方面，與當(dāng)前創(chuàng)建應(yīng)用程序的方式相比 .NET都具有的優(yōu)勢。 190 C++框架 ? ACE ? BOOST ? MFC ? ATL ? QT ? wxWidgets ? … 191 不同層次的模式 ? 架構(gòu)模式 (Architectural Pattern) ? 設(shè)計模式 (Design Pattern) ? 代碼模式 (Coding Pattern) 192 ? 區(qū)別：在于三種不同的模式存在于它們各自的抽象層次和具體層次。 ? 架構(gòu)模式是一個系統(tǒng)的高層次策略，涉及到大尺度的組件以及整體性質(zhì)。架構(gòu)模式的好壞可以影響到總體布局和框架性結(jié)構(gòu)。 ? 設(shè)計模式是中等尺度的結(jié)構(gòu)策略。這些中等尺度的結(jié)構(gòu)實現(xiàn)了一些大尺度組件的行為和它們之間的關(guān)系。模式的好壞不會影響到系統(tǒng)的總體布局和總體框架。設(shè)計模式定義出子系統(tǒng)或組件的微觀結(jié)構(gòu)。 ? 代碼模式是特定的范例和與特定語言有關(guān)的編程技巧。代碼模式的好壞會影響到一個中等尺度組件的內(nèi)部、外部的結(jié)構(gòu)或行為的底層細(xì)節(jié)，但不會影響到一個部件或子系統(tǒng)的中等尺度的結(jié)構(gòu)，更不會影響到系統(tǒng)的總體布局和大尺度框架。 193 幾種典型的架構(gòu)模式 ? 系統(tǒng)軟件 ? 分層 (Layer) ? 管道和過濾器 (Pipes and Filters) ? 黑板 (Blackboard) ? 開發(fā)分布式軟件 ? 經(jīng)紀(jì)人 (Broker) ? 客戶 /服務(wù)器（ Client/Server） ? 點對點（ Peer to Peer） ? 交互軟件 ? 模型 視圖 控制器（ ModelViewController） ? 顯示 抽象 控制（ PresentationAbstractionCOntrol） 194 其它 ? 面向?qū)ο箫L(fēng)格 (ADT) ? 基于消息廣播且面向圖形用戶界面的 Chiron2風(fēng)格 ? 基于事件的隱式調(diào)用風(fēng)格 (Eventbased, Implicit Invocation) ? … 195 分層 (Layer) ? 從不同的層次來觀察系統(tǒng)，處理不同層次問題的對象被封裝到不同的層中。 ? 軟件為什么要分層？ 為了實現(xiàn)“高內(nèi)聚、低耦合”。把問題劃分開來各個解決，易于控制，易于延展，易于分配資源 … ? 面向?qū)ο蟮?、基于模塊化的組件設(shè)計需要能夠方便地修改應(yīng)用程序的各個部分。完成這一目標(biāo)的一種好方法就是在層上工作，將一個應(yīng)用程序的主要功能分離到不同的層或者級中。 196 分層模型 ? 從本質(zhì)上講，層代表了一個應(yīng)用程序主要的功能。一般地，我們將應(yīng)用程序功能分為三個方面，對應(yīng) 3層架構(gòu)模式。它們是數(shù)據(jù)層（ data layer）、商務(wù)層（ business layer）和表示層（ presentation layer）。 ? 數(shù)據(jù)層：包含數(shù)據(jù)存儲和與它交互的組件或服務(wù)。這些組件和服務(wù)在功能上和中間層相互獨立（盡管在物理上不必一定相互獨立 它們可以在同一臺服務(wù)器上）。 ? 中間層：包括一個或者多個組件服務(wù)，它們應(yīng)用商務(wù)規(guī)則、實現(xiàn)應(yīng)用程序邏輯并完成應(yīng)用程序運行所需要的數(shù)據(jù)處理。作為這個過程的一部分，中間層負(fù)責(zé)處理來自數(shù)據(jù)存儲或者發(fā)送給數(shù)據(jù)存儲的數(shù)據(jù)。 197 ? 表示層：從中間層獲得信息并顯示給用戶。該層同時也負(fù)責(zé)和用戶進行交互，比較返回的信息并將信息回送給中間層進行處理。 ? 數(shù)據(jù)層從數(shù)據(jù)庫中獲得較為原始的數(shù)據(jù)，商務(wù)層把數(shù)據(jù)轉(zhuǎn)換成符合商務(wù)規(guī)則的有意義的信息，表示層把信息轉(zhuǎn)換成對于用戶有意義的內(nèi)容。 ? 這種分層設(shè)計方式很有用，因為每一層都可以獨立地修改。我們可以修改商務(wù)層，不斷地從數(shù)據(jù)層接受相同的數(shù)據(jù)，并把這些數(shù)據(jù)傳遞到表示層，而不用擔(dān)心出現(xiàn)歧義。我們也可以修改表示層，使得對于站點外觀的修改不必改動下面的商務(wù)層邏輯。 198 管道和過濾器（ Pipes and Filters） ? 管道和過濾器架構(gòu)模式是為處理數(shù)據(jù)流的系統(tǒng)提供的一種模式。它是由過濾器和管道組成的 .每個處理步驟都被封裝在一個過濾器組件中，數(shù)據(jù)通過相鄰過濾器之間的管道進行傳輸。每個過濾器可以單獨修改，功能單一，并且它們之間的順序可以進行配置。 199 ? 一個著名的例子是傳統(tǒng)的編譯器。傳統(tǒng)的編譯器一直被認(rèn)為是一種管道系統(tǒng)，在該系統(tǒng)中，一個階段（包括詞法分析、語法分析、語義分析和代碼生成）的輸出是另一個階段的輸入。 200 ? 問題： ? 一個必須處理或轉(zhuǎn)換輸入數(shù)據(jù)流的系統(tǒng)。把這樣的系統(tǒng)作為單個組件實現(xiàn)是不容易的： – 系統(tǒng)必須由幾個開發(fā)人員同時進行協(xié)作開發(fā)，整個系統(tǒng)任務(wù)自然就被分解為幾個處理階段，而且需求很容易變動。因此你就要通過替換或重新排序處理步驟來為將來的靈活性作規(guī)劃。通過加入這樣的靈活性，采用現(xiàn)有處理組件構(gòu)建是可以辦到的。 ? 系統(tǒng)的設(shè)計尤其是處理步驟的內(nèi)部連接，必須考慮以下因素： – 未來系統(tǒng)的升級通過替換某些處理步驟，或重組步驟。 – 不同的語境中小的處理步驟要比大的組件更易于重用。 – 不相連的處理步驟不可共享信息。 – 存在不同的輸入數(shù)據(jù)源，可以用多種方式輸出或存放最終結(jié)果。 201 解決方案與結(jié)構(gòu) ? 管道和過濾器體系架構(gòu)模式把系統(tǒng)任務(wù)分成為幾個獨立的處理步驟。這些步驟采用通過系統(tǒng)的數(shù)據(jù)流連接。一個步驟的輸出是下一個步驟的輸入。每個處理步驟由一個過濾器組件實現(xiàn)，它處理或者轉(zhuǎn)化數(shù)據(jù)，并且系統(tǒng)的輸入可以是多種數(shù)據(jù)源。 ? 這種體系架構(gòu)模式具有許多特性： – 過濾器是獨立運行的部件。也就是除了輸入和輸出外，每個過濾器不受任何其他過濾器運行的影響。在設(shè)計上，過濾器之間不共享任何狀態(tài)信息。 – 獨立性還表現(xiàn)在它對其處理的上游和下游連接的過濾器是 無知 的 .它的設(shè)計和使用不對與其連接的任何過濾器施加限制，唯一關(guān)心的是其輸入數(shù)據(jù)的，然后進行加工處理，最后產(chǎn)生數(shù)據(jù)輸出。 202 優(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)的流之間的對應(yīng)關(guān)系。 ? 同實現(xiàn)有關(guān)，過濾器之間的數(shù)據(jù)傳輸率較低，而且每個過濾器都要作類似的數(shù)據(jù)打包和解包的工作。 203 黑板 (Blackboard) ? 又稱看板模式：在這種架構(gòu)中，有兩種不同的構(gòu)件：一種是表示當(dāng)前狀態(tài)中心數(shù)據(jù)結(jié)構(gòu)；另一種是一種相互獨立的構(gòu)件，這些構(gòu)件對中心數(shù)據(jù)進行操作。這種架構(gòu)主要用于數(shù)據(jù)庫和人工智能系統(tǒng)的開發(fā)。 ? 模式識別、數(shù)據(jù)挖掘。 204 經(jīng)紀(jì)人 (Broker) ? 客戶和服務(wù)器通過一個經(jīng)紀(jì)人部件進行通信，經(jīng)紀(jì)人負(fù)責(zé)協(xié)調(diào)客戶和服務(wù)器之間的操作，并且為客戶和服務(wù)器發(fā)送請求和結(jié)果信息。 205 ? 代理程序駐留在一個不應(yīng)該頻繁更改的、眾所周知的位置。已被激活并且準(zhǔn)備接收請求的任何服務(wù)器都將向代理程序注冊自己，以便下一次客戶端向代理程序請求這種類型的服務(wù)器時，代理程序能夠使用它。這還可能提高系統(tǒng)的性能和可用性，因為它使您可以擁有多個同時運行并服務(wù)于多個客戶端的、完全相同的服務(wù)器組件。這種機制有時稱為負(fù)載平衡。 206 客戶 /服務(wù)器（ Client/Server） ? 系統(tǒng)分為客戶和服務(wù)器，服務(wù)器一直處于偵聽的狀態(tài)，客戶主動連接服務(wù)器，每個服務(wù)器可以為多個客戶服務(wù)。 207 優(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ù) clientserver風(fēng)格的系統(tǒng)中，構(gòu)件之間的連接通過（遠(yuǎn)程）過程調(diào)用，接近于代碼一級，表達(dá)能力較弱。 208 點對點（ Peer to Peer） ? 系統(tǒng)中的節(jié)點都處于平等的地位，每個節(jié)點都可以連接其他節(jié)點。在這種架構(gòu)中，一般需要由一個中心服務(wù)器完成發(fā)現(xiàn)和管理節(jié)點的操作。ICQ以及 Web Service技術(shù)的大多數(shù)應(yīng)用，都是典型的點對點結(jié)構(gòu)。 209 模型 視圖 控制器（ 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)靈活、重用性好、擴展性佳。 210 模型 —視圖 —控制器交互的示意圖 211 模型：視圖：控制器 : ? 模型： ? 模型表示應(yīng)用的數(shù)據(jù)及操作這些數(shù)據(jù)的邏輯方法。任何和整個應(yīng)用有關(guān)的持久性數(shù)據(jù)都應(yīng)該放在模型中。對于模型 ,它所提供的 API不能只針對某一個專門的視圖或控制器 ,應(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)該在視圖中存取。 212 SOA 及分層架構(gòu)設(shè)計 213 SOA的架構(gòu)的特點 ? 服務(wù)（ Service） – 定義良好的，自包含的，不依賴于上下文和其它服務(wù)的一組功能 ? SOA（ ServiceOriented Architecture） – 本質(zhì)上是一組服務(wù)的集合 – 服務(wù)之間相互溝通 ? 可以是簡單的數(shù)據(jù)傳輸，或者是由兩個或多個服務(wù)共同參與的一些活動， SOA也包括 Service之間的連通技術(shù)。 214 ? OO vs. SOA ––OO的擴展遇到了挑戰(zhàn) ? 隨著時間的推移，接口繼承的復(fù)雜度在累積 ? 隨著系統(tǒng)間距離的延伸，調(diào)用成本在上升，類型系統(tǒng)的不同步 ? 擴展組件的功能成本高，不可確定未來需求，不可堆疊的擴展方式 ? 重用與標(biāo)準(zhǔn)化，重用是 OO的第一原則，難以維持和維護復(fù)雜的重用標(biāo)準(zhǔn)和機制 215 ? –OO vs. SOA – OO仍然適用于服務(wù)的開發(fā) ? 明顯的性能優(yōu)勢 ? 成熟的設(shè)計與開發(fā)方法 – SOA適用于系統(tǒng)的互聯(lián) ? 互操作性的要求強于性能的要求 216 ? SOA 既不是一種語言，也不是一種具體的技術(shù)，它是一種新的軟件系統(tǒng)架構(gòu)模型。 SOA 最主要的應(yīng)用場合在于解決在 Inter環(huán)境下的不同商業(yè)應(yīng)用之間的業(yè)務(wù)集成問題。 ? SOA 架構(gòu)的出現(xiàn)為企業(yè)系統(tǒng)架構(gòu)提供了更加靈活的構(gòu)建方式，如果企業(yè)架構(gòu)設(shè)計師基于 SOA 來構(gòu)建系統(tǒng)架構(gòu)，就可以從底層架構(gòu)的級別來保證整個系統(tǒng)的松耦合性以及靈活性，這都為未來企業(yè)業(yè)務(wù)邏輯的擴展打好了基礎(chǔ)。 217 ? 特性： – 松耦合性 ? 松耦合性要求 SOA 架構(gòu)中的不同服務(wù)之間應(yīng)該保持一種松耦合的關(guān)系，也就是應(yīng)該保持一種相對獨立無依賴的關(guān)系； – 位置透明性 ? 位置透明性要求 SOA 系統(tǒng)中的所有服務(wù)對于他們的調(diào)用者來說都是位置透明的，也就是說每個服務(wù)的調(diào)用者只需要知道他們調(diào)用的是哪一個服務(wù)，但并不需要知道所調(diào)用服務(wù)的物理位置在哪里； – 協(xié)議無關(guān)性。 ? 協(xié)議無關(guān)性要求每一個服務(wù)都可以通過不同的協(xié)議來調(diào)用。