我們已將大部分注意力集中在為信息工作者提供業(yè)務智能 (BI) 工具上面，以幫助他們作出更明智的決策。其中的大多數(shù)企業(yè) BI 解決方案都是通過各種資源，尤其是通過使用某種形式的服務器端信息集成來提供信息。無論是用于匯總數(shù)據(jù)的報告系統(tǒng)、類似于 Microsoft? SharePoint? 的協(xié)作工具，還是用于提供業(yè)務流程管理的自定義企業(yè)應用程序集成 (EAI) 解決方案，此信息發(fā)揮的實際作用才是重點。無需過多考慮如何使用此信息。
對于大多數(shù)活動來說，信息工作者在制定決策時需要參考以下幾個應用程序：用于查看門戶站點的 Web 瀏覽器、用于訪問 EAI 解決方案的自定義應用程序以及用于讀取數(shù)據(jù)匯總的報表查看器。隨著時間的推移，通過學習如何跨應用程序邊界手動收集和整理數(shù)據(jù)，工作人員在工作方面是越來越精通。這通常要通過啟動 Microsoft Outlook?、Word、Excel?、Internet Explorer? 以及由公司提供的各種自定義應用程序等一系列過程來實現(xiàn)。這種轉椅集成形式會產(chǎn)生不良后果：對新用戶的培訓時間過長、系統(tǒng)不能以正確的形式為正確的人員提供正確的信息、引入了數(shù)據(jù)錯誤問題，等等。那么，提供一個由部署模型包圍的安全集成和托管載體，從而使這種形式的應用程序集成變得更方便，是不是會更有效呢？
多數(shù)開發(fā)人員認為面向服務的體系結構 (SOA) 是提供信息的方式，而不是使用信息的方法。但您如何處理所有的自動化孤島呢？由此引入了集成式桌面這一觀點。
作為解決方案體系結構，我們旨在簡化不斷擴展的業(yè)務應用程序領域并豐富用戶的經(jīng)驗，但是，其中最難以達到的一個目標就是跨過在桌面上運行的多個應用程序無縫集成解決方案。諸如 DDE、OLE、COM、mailslot 及類似技術已全部用于解決本地應用程序集成問題。但得到的卻是經(jīng)過高度耦合、容易遭到破壞的桌面應用程序，而維護和部署這些應用程序卻要花費高昂的代價。
集成式桌面是側重于桌面的已連接系統(tǒng)體系結構的最新部分。集成式桌面是一個松散耦合的托管體系結構，也是在桌面上運行的復合 UI，它由后端的松散耦合體系結構予以支持。它大大減少了必須由用戶處理的應用程序的數(shù)目，并將一切置于單片“玻璃”下。構建集成式桌面應用程序所需的全部技術已事先存在于 .NET Framework 中。但是，時至今日所面臨的主要挑戰(zhàn)仍是如何將它們無縫集成在一起。
集成式桌面策略的潛在方向是啟動服務。雖然體系結構并非一定需要服務結構，但對于構建組合企業(yè)桌面的策略而言，服務結構卻是必要的。集成式桌面應用程序的松散耦合本質(zhì)就是對啟用服務后端的自然適用。保持松散耦合體系結構的屬性可順利完成部署，但這些種類的體系結構在部署時常常會遇到干擾。
對于 Microsoft，實現(xiàn)集成式桌面的基礎層是新一代 Composite UI Application Block (CAB) 和 Smart Client Software Factory。對于精心制作個人桌面框架和自定義應用程序的解決方案架構師而言，將這兩個工具結合起來使用將會提供強大的功能。（繼續(xù)之前，請先熟悉一下提要欄“
基本術語”中出現(xiàn)的術語。）
CAB 工作原理
CAB 是用于構建復雜的智能客戶端應用程序的模式和概念的實現(xiàn)。簡單來說，它提供 Windows? Forms 探測功能，以幫助構建企業(yè)桌面應用程序。
由于僅介紹 CAB 就能占據(jù)整篇文章的篇幅，而且其中有幾個組件還超出了本文所探討的范圍。因此，我們將側重于 CAB 的主要組件，但建議您下載該部分內(nèi)容并做深入的研究。 從訪問
CAB 社區(qū)站點開始。
CAB 旨在支持多種應用程序方案，如在線事務處理 (OLTP) 前端、客戶端門戶以及信息工作者應用程序。由于 CAB 是模塊化設計且接觸面積較小，因此，它不但適用于大型集成式桌面，甚至還適用于簡單的智能客戶端。
利用 CAB，可通過正確解耦界面的各組成部分來共享單個智能客戶端界面的開發(fā)任務。最終，CAB 改進了重復使用，并能夠輕松實現(xiàn)內(nèi)部應用程序工作流之類的概念。為了能夠重復使用，通過使用 CAB 框架構建的復合 UI 被分為多個工作部件。驅動程序是應用程序的外殼，它相當于托管可執(zhí)行程序及用于加載復合 UI 部件的引導程序。由外殼加載和顯示的 UI 元素為用戶提供“接觸點”，如菜單和其他導航組件。外殼與應用程序部件自行松散耦合，因此，它為 UI 設計提供了一種靈活的方法。雖然外殼和 CAB 服務握著方向盤，但必須由您為引擎提供將由外殼托管的應用程序。
除了為托管可重用的部件提供框架之外，CAB 還為諸如加載模塊、通信消息、保持狀態(tài)等任務提供了一套智能客戶端核心服務?？赏ㄟ^代碼或應用程序的 .config 文件來添加這些服務。這些核心服務包括：
模塊加載程序和模塊枚舉服務是基于提供商的服務，用于對列在配置目錄中的模塊的讀取和加載操作進行控制。
事件代理服務用于在部件間以及由復合 UI 托管的子應用程序間傳遞消息。
身份驗證服務是基于提供商的服務，它負責詢問用戶的憑據(jù)、訪問證書以及聯(lián)系后端數(shù)據(jù)提供商。
狀態(tài)持久性服務是基于提供商的存儲服務，它用于保存工作項狀態(tài)，以便共享上下文數(shù)據(jù)，以及暫停工作項并在稍后重新激活。
要為 CAB 應用程序構建引擎，通常需要首先創(chuàng)建一個 CAB 模塊。模塊將為您的個人功能集提供一個可部署入口點（有時稱為托管的應用程序）。模塊包含在各自的 DLL 文件中并在運行時從外殼加載。對于哪些模塊可用以及加載哪些模塊，這是完全可以進行配置的，這由可擴展程序目錄來實現(xiàn)。如果您熟悉 Microsoft Enterprise Library，您會在 CAB 中識別出同一提供程序模型。在 Visual Studio? 中，無需直接在外殼項目中引用模塊，而且模塊從未直接綁定到可執(zhí)行程序。而是在運行時由模塊加載程序加載這些模塊。
在模塊程序集內(nèi)部，可借助 CAB 和 Smart Client Software Factory 類型（如 Presenter、SmartPart 和 State）提供實現(xiàn)該功能集所必需的工作項、視圖、控制器和數(shù)據(jù)。尤其是這三項形成了基于 CAB 應用程序的 Model-View-Presenter/Model-View-Controller (MVP/MVC) 模式。當應用程序邏緝需要時，注入服務。這允許開發(fā)人員以動態(tài)方式創(chuàng)建新的對象實例或返回已在容器中創(chuàng)建的對象。對于 CAB 來說，該容器是工作項，而且也是模塊開發(fā)人員最先創(chuàng)建的內(nèi)容之一?？赏ㄟ^使用 AddNew，將 CAB 組件（如客戶端服務和工作區(qū)）顯式添加到該容器中：
_rootWorkItem.WorkItems.AddNew<WorkItemA>();
也可通過配置或以聲明的方式來實現(xiàn)這一操作：
[CreateNew]public ShipNewOrderViewPresenter Presenter{set{_presenter = value;_presenter.View = this;}}
在容器（工作項）范圍內(nèi)，也可根據(jù)需要，以聲明的方式將這些組件解除引用。這就提供了一種松散耦合方式，以獲得對所有包含在內(nèi)的、由 CAB 管理的項的訪問權限（注入），如下所示：
[ServiceDependency]public WorkItem WorkItem{set { _workItem = value; }}
CAB 的一個關鍵組件是對象生成器（也供新版本的 Enterprise Library 使用）。只要實現(xiàn)此依賴性注入，對象生成器就能啟用大量有用的功能。它能夠在適當?shù)臅r候創(chuàng)建一個新的具體類實例或返回現(xiàn)有的類實例；它能夠在某個類提供多個實例時，選擇合適的構造函數(shù)；它能夠響應屬性和方法中所聲明的屬性 (attribute)，這些屬性 (attribute) 會影響新對象的創(chuàng)建和命名；它還能夠提供拆除工具，通過反轉操作鏈，將設置從現(xiàn)有的對象中刪除。
對象生成器的實用性很低，并且在多數(shù)情況下，您不能直接與其交互。然而，了解“依賴性注入”的概念對于了解如何將服務插入到模塊中是非常重要的，而且在調(diào)試時這些知識會對您大有幫助。有關“依賴性注入”和 CAB 中所使用的其他模式的詳細信息，請參考 CAB 文檔。
可按照您希望的方式劃分模塊。每個模塊至少應存在一個工作項，另外的工作項作為該模塊的驅動程序。像其他任何應用程序或子應用程序一樣，也可按照您的意愿確定工作項的大小。在 CAB 應用程序中，事件的典型順序與以下類似：
1.
用戶雙擊用于顯示外殼的 EXE。
2.
外殼引導桌面，加載任何已配置的 CAB 服務，顯示其 UI 元素，然后加載所有已配置的模塊。
3.
當被加載后，每個模塊都會將一個工作項添加到其父工作項來控制該子應用程序，并讓此工作項在所提供的工作區(qū)中顯示其任一內(nèi)容。
4.
當被加載后，每個模塊都會將一個工作項目添加到其父工作項目來控制該子應用程序，并讓此工作項目在所提供的工作區(qū)中顯示其任一內(nèi)容。
5.
當用戶從菜單中選擇一個 UI 元素時，即會引發(fā)相關聯(lián)的命令。
6.
命令處理程序會通過添加一個子工作項目來響應該命令，該工作項目將控制另一個子應用程序并顯示其視圖。
7.
該工作項目通過智能部件顯示其視圖。
8.
用戶與視圖接口進行交互，隨后視圖接口再傳遞一個控制器（或表示器）。
9.
控制器更改共享數(shù)據(jù)（狀態(tài)）并使用事件代理將數(shù)據(jù)傳回主機。
10.
事件代理將該相關信息（上下文）發(fā)送到其他模塊或部件。
CAB 模塊可以是獨立的整體，也可以是由外殼所托管的一個大型模塊集的一部分。多模塊智能客戶端是 CAB 真正體現(xiàn)其靈活性和設計的亮點所在。此靈活性主要體現(xiàn)在，您根本不必在加載模塊程序集的外殼項目中直接引用模塊程序集，因為它們將在運行時由 CAB 加載。此外，單個模塊中的各個部件可以相互通信，也可以與外部模塊（均包含在其各自的程序集中）中運行的各部件進行通信。
返回頁首構建簡單的 CAB 應用程序
現(xiàn)在，讓我們構建一個單模塊應用程序。首先，我將粗略說明如何創(chuàng)建一個簡單的智能客戶端。（我將在后文中討論更復雜的集成式桌面。）
多數(shù)集成式桌面都具有一個可見的啟動窗體，因此您通常都從一個“Windows 窗體”外殼開始操作。首先，從 FormShellApplication 繼承您的類并將其實例化，然后從您的應用程序的 Main 方法調(diào)用其 Run 方法。這將初始化 CAB 應用程序，從而加載我們先前討論的任何已配置服務。下一步涉及到覆蓋 FormShellApplication 提供的方法（例如 AfterShellCreated）以填充菜單和顯示任何可見視圖。（智能部件是可選項，它們只是用 SmartPartAttribute 裝飾的用戶控件。）
要在實現(xiàn) AfterShellCreated 時初始化用戶界面，您需要將 CAB 所引用的內(nèi)容注冊為擴展站點。這會提供一個 UI 元素管理器，以便任何模塊在以后任何時候都可以添加來自任何模塊的子 UI 元素（例如，菜單項或工具欄項）。最后，在外殼對通常也在此初始化期間添加的 UI 元素命令進行加載或響應時，您開始顯示您的視圖。由于各命令綁定了命令處理程序，因此您的代碼在運行時可以對任何普通 UI 元素引發(fā)的任何命令作出響應；這與添加通常的事件處理程序相似，只不過方式更為抽象一些。
可通過使用 SmartPartPlaceHolder 類或 CAB 中稱為工作區(qū)的區(qū)域來顯示視圖。它們只是用于以給定排列方式顯示視圖的布局容器。如果您曾使用過 Java 抽象窗口工具包 (AWT)，您就應熟悉此概念。
最后，要創(chuàng)建外殼，請注冊一個接口并顯示一個智能部件。提要欄中的“
創(chuàng)建簡單的智能客戶端：分步指南”詳細介紹了如何構建一個非常簡單但模塊化的智能客戶端。要展現(xiàn) CAB 的真正功能，您應使用模塊將您的各部件封裝到各自的程序集中。這為您提供了設計時抽象以及類似于 COM 提供的運行時抽象，但消除了所有復雜性。
使用各模塊，您可以托管通過功能集自身的程序集部署的獨立功能集。這意味著各組織可以在不影響整個集成式桌面的情況下對各個模塊進行版本處理、部署和功能增強。模塊程序集文件（不直接在 EXE 中引用）在運行時通過模塊加載程序和枚舉服務進行加載。CAB 的配置文件目錄和應用程序配置文件使您可以指定要將哪些模塊加載、部署和綁定到外殼中。提要欄中的“
創(chuàng)建模塊和模塊初始化程序”將逐步向您介紹創(chuàng)建模塊及其初始化程序的過程。我所羅列出的步驟清楚描述了如何創(chuàng)建一個簡單的 CAB 應用程序。但是請注意，我們此處論及的只是問題的表面。
隨 CAB 一起安裝的“Bank Teller”快速入門示例是一個現(xiàn)成的單模塊 CAB 應用程序。它將向您介紹我在此處所概述的所有關鍵組件。
當然，當構建真正的企業(yè)集成式桌面時，會涉及到更多內(nèi)容，而不僅僅是復合的 UI 塊這么簡單。您需要解決大量復雜問題，例如，如何在模塊間共享信息、如何將非 CAB 應用程序集成到桌面中、如何處理安全問題以及如何控制布局。
返回頁首Smart Client Software Factory 簡介
在創(chuàng)建企業(yè)就緒型應用程序時，除了 CAB 提供的核心服務之外，您還需要其他類的基礎服務。這些服務包括幫助您在部署、安全性和置備等方面管理桌面的工具。您可能還需要日志記錄、工作流、配置和緩存處理之類的服務，以確保所有模塊在這樣松散耦合的環(huán)境中正常運行。
Smart Client Software Factory 可以通過提供指南和引用實現(xiàn)來助您一臂之力。Smart Client Software Factory 不僅僅是一個工具包，它還提供了智能客戶端基本核心服務的使用入門集，以幫助您著手建立企業(yè)就緒型集成式桌面。
所有服務均可視為可選服務和可擴展服務。Smart Client Software Factory 構建于 CAB 和 Enterprise Library 之上，并利用了現(xiàn)有應用程序塊。圖 1 例示了借助 Smart Client Software Factory 構建的智能客戶端服務的體系結構。
圖 1 智能客戶端服務
因為多數(shù)公司都需要一組常用服務，因此 Microsoft 已將一個相關資產(chǎn)集合內(nèi)置于 Smart Client Software Factory 中。它們由兩個引用實現(xiàn)來凸顯，這兩個引用實現(xiàn)可將典型經(jīng)驗映射到 Smart Client Software Factory 內(nèi)所包含的服務。“引用實現(xiàn) 1”模擬了“貸款評估桌面”并利用了離線工作能力、最終用戶通知和其他類似功能?！耙脤崿F(xiàn) 2”模擬了“銀行職員桌面”（Bank Teller 示例的一個多模塊版本）以演示安全服務、部署服務和主題服務。
指南包所提供的幫助對構建企業(yè)應用程序非常有價值。它們使用相對較新的 Guidance Automation Toolkit (GAT)（該工具包是對 Visual Studio 2005 的擴展）構建而成。在使用 GAT 時，團隊開發(fā)人員可以提供啟動工具包（或 SDK），這樣其他開發(fā)人員就可以在將來添加模塊和其他 ID 部件。Smart Client Software Factory 包括一個必不可少的元素，即用于智能客戶端開發(fā)的 Visual Studio Guidance Package。這是由指導 ID 開發(fā)人員經(jīng)歷整個 CAB 開發(fā)生命周期的工具、模式、源代碼和說明性指導組成的一個集成式集合。若想了解詳細信息以及下載 GAT，請訪問
msdn.microsoft.com/vstudio/teamsystem/Workshop/gat/default.aspx。
返回頁首基本的智能客戶端服務
集成式桌面構建于 Smart Client Software Factory 和 CAB 之上。它應采用一個可重用集合的形式，這個集合由 CAB 擴展、Smart Client Software Factory 實現(xiàn)、普通基礎服務以及可整體或部分添加到任何現(xiàn)有復合 UI 應用程序中的庫組成。這就構成了“集成式桌面框架”，其中包含一些基本服務。
上下文服務 這是創(chuàng)建集成式桌面的最重要元素之一。它也很可能是最容易被理解錯誤的元素之一。當使用由若干模塊組成的 CAB 應用程序時，您通常會采用某種形式的信息共享。例如，您的 CAB 應用程序可能包括一個外殼、一個用于顯示客戶信息的模塊、一個用于顯示匯總數(shù)據(jù)的標題模塊、一個搜索模塊以及其他任務特定的模塊。其中每一個模塊都可以單獨開發(fā)、部署和維護。如果您想探究如何實現(xiàn)這些任務，可以借助提供了相關“方法”的 CAB。但您還需要確定“內(nèi)容”，也就是將在這些模塊之間共享的信息。這可能僅指客戶 ID。事件代理會將“上下文已更改”這樣的事件進行全局通信，并且所有模塊都會在相應時間顯示相應信息。您將廣播客戶 ID 這樣的事實說明它是要共享的信息，并且這形成了“上下文”的前提。
上下文服務只用于廣播和檢索這些共享信息，在某種程度上，這與企業(yè)桌面所提出的策略一致。您應采用一組基本的上下文類型及其相應的架構合約才能在您的桌面中提供其他任何服務。這類似于 SOA 中所使用的“合約至上”的設計實踐。您并不是要遵守在 Web 服務端點所定義的合約，而是要在桌面自身的各部件之間定義這些相同的合約。實際上，在構建集成桌面應用程序時，也存在 EAI 或 SOA 項目中存在的相同難題。
部署服務 這些服務通過確保各個模塊可以在運行時部署到桌面來提供集成式桌面應用程序及其部件。一個選擇是將部署服務構建于 ClickOnce API 之上。這些服務應該對要下載到桌面的特定可選模塊提供服務器端控制。當外殼啟動時，身份驗證服務將為部署服務提供證據(jù)來證明：已為用戶啟用特定模塊，這樣，如果這些模塊已不存在，則必須將其下載到桌面。模塊將被下載，并由模塊加載程序進行加載，然后在需要時顯示給用戶。CAB 使您可以向配置文件目錄添加用戶角色。部署服務的實現(xiàn)程序可以輕松地擴展通常的模塊加載程序服務以利用此功能，因為 CAB 在模塊加載程序擴展中將只對在當前附加到運行主體的已知角色條件下被授權運行的模塊調(diào)用加載。
安全服務 與上下文服務不同，安全服務非常易于理解。您可以將其構建于所提供的在 CAB 中已有的身份驗證服務之上。這為使用自定義身份驗證服務提供了一個起點，并提供了一種向集成式桌面應用程序統(tǒng)一添加身份驗證邏輯的方法。使用 CAB 和 Smart Client Software Factory 提供的服務及指南，您可以將各角色添加到各個模塊中，以指明這些模塊與特定角色相關聯(lián)。這使您可以根據(jù)登錄者的角色控制要加載哪些模塊，并可以啟用其他功能（例如您的部署服務）來控制實際要將哪些模塊部署到桌面。
集成服務 如果受管的 Windows 窗體應用程序是要集成到智能客戶端中的唯一候選程序，則部署單個企業(yè)桌面就沒有太大用處。通常需要集成大量的預編寫（傳統(tǒng)）應用程序，以便它們在保持自治性的同時仍可作為桌面體驗的一部分。其中包括不是用 .NET 創(chuàng)建的 Web 應用程序、ASP.NET Web 應用程序、COM 應用程序，甚至包括綠屏。
Smart Client Software Factory 中的集成服務提供了將這些服務中的某些服務內(nèi)置于您的集成式桌面中的指南。本文將特別介紹一種類型的傳統(tǒng)桌面應用程序集成 - Web 應用程序。我們將向您介紹 CAB 和 Smart Client Software Factory（及其指南包）如何幫助您構建一個可以采用任何 Web 應用程序并可以輕松將其托管的 Web 模塊。
返回頁首集成式桌面的功能層
一個集成式桌面由三層組成：基礎層、平臺層和應用程序層。在開發(fā) ID 解決方案時，了解這些層以及它們將影響體系結構的哪些等級是至關重要的。圖 2 例示了這些層與集成式桌面體系結構中各個級別之間的關系。
圖 2 集成式桌面體系結構
基礎層 該層包含了 CAB 提供的所有核心客戶端服務，以及可以由任何模塊或智能部件使用的安全性和部署之類的服務。這些服務代表了桌面的聯(lián)合水平組件。CAB 和 Smart Client Software Factory 均提供了基礎層的主要部分。在構建“集成式桌面框架”時，首先需要著手處理的就是該層及其相應的客戶端服務。
平臺層 該層針對的是提供特定于平臺或技術的元素（例如由傳統(tǒng)服務處理的元素）的服務。它由模塊或智能部件開發(fā)人員可用來合并部件（要考慮到它們所源于的平臺）的組件構成。如果您有多個 Web 應用程序需要集成到桌面，則提供可重用的客戶端 Web 應用程序服務來作為“集成式桌面框架”的一部分將有助于托管這些應用程序。例如，您可能想要使用已經(jīng)在生產(chǎn)環(huán)境中運行的現(xiàn)有購物車應用程序。來自平臺層的服務可以用于在桌面托管此應用程序，使其像其他任何受管模塊一樣工作。Smart Client Software Factory 提供了一組傳統(tǒng)服務來作為該層的一部分。
應用程序層 僅包含應用程序和可重用的客戶端業(yè)務功能，此應用程序層提供了特定于業(yè)務的客戶端服務。該層由您通常需要進行交互的模塊組成，例如搜索模塊、客戶信息模塊和購物車模塊。
返回頁首集成傳統(tǒng) Web 應用程序
在 CAB 應用程序中托管現(xiàn)有 Web 應用程序所需要的不僅僅是向智能部件添加一個瀏覽器控件?？蛻舳思傻囊c是所有應用程序（或模塊）均已完全集成。這意味著它們可以雙向通信和共享信息。直到 CAB 可用，此功能才可行，但解決方案只是說明性的，離可重復使用還差得很遠。
但正如上面提到的，現(xiàn)在可以創(chuàng)建 Web 模塊來托管任何 Web 應用程序。而且您可以做到這些，無需任何其他模塊了解其中的差異?，F(xiàn)有模塊從未需要改變它們共享信息的方式。
現(xiàn)在我們將逐步介紹構建簡單 Web 模塊（如圖 3 中所示的模塊）的過程，這要依賴于由 Smart Client Software Factory 團隊提供的指南。我們使用 CAB 服務以及由 Smart Client Software Factory 提供的新的指南包。
圖 3 由 Web 模塊托管的 Web 應用程序
您需要做的第一件事是新建一個 Web 應用程序或擴展現(xiàn)有的應用程序。本示例概述了創(chuàng)建新 ASP.NET Web 應用程序的步驟。您也可以將其用作修改現(xiàn)有 Web 應用程序的模板。我們使用的過程稍微有點侵略性：您必須將 JScript? 添加到應用程序，而且在設計時通過添加代碼利用對象模型與 Web 應用程序通信。
在創(chuàng)建樣例 Web 頁面（該頁面將用作典型 Web 應用程序）后，創(chuàng)建一個 Web 模塊。但在這樣做之前，必須下載以下必備條件：
?
Guidance Automation Extensions (GAX)
?
Composite UI Application 指南包（確保在當前解決方案中啟用此功能）
?
Composite UI Application Block
?
包含到 CAB 庫和 Smart Client Software Factory 的適當引用的簡單外殼應用程序
?
包含所有可在某些其他模塊和應用程序庫中重復使用的公用代碼的庫項目
作為 Smart Client Software Factory 的一部分，諸如 Microsoft.Practices.SmartClient.Web.WebPresenter 和 Microsoft.Practices.SmartClient.Web.WebView 之類的類提供基本探測功能，以便使用 CAB 的事件代理自動映射由 Web 頁面觸發(fā)的事件。從而使任意 Web 模塊能夠利用內(nèi)置于 CAB 中的默認通信機制，并能夠使所有事件自動流入和流出 Web 頁面。Microsoft.Practices.SmartClient.Web.WebView 繼承自瀏覽器控件，可在 Web 模塊中重復使用。
請注意，指南包是可選的，并且僅自動提供您的項目中的一些模板代碼，如 Smart Client Software Factory 提供的服務。作為替代方法，您也可以從本文下載樣例 Web 頁面和 Web 模塊。
步驟 1：創(chuàng)建 Web 頁面 我們將從創(chuàng)建 Web 頁面著手，該頁面將用作我們的傳統(tǒng) Web 應用程序。
1.
新建一個 Web 項目或向現(xiàn)有 Web 項目中添加一個新頁面。
2.
或者，向可能包含 Web 應用程序所使用的常量的任何公用庫中添加引用。
3.
添加一個 HTML 按鈕，其“Text”（文本）屬性值為“觸發(fā)上下文已更改的事件（來自 JavaScript）”。
4.
添加一個 ASP.NET 按鈕，其“Text”（文本）屬性值為“觸發(fā)上下文已更改的事件（來自 ASP.NET 服務器）”。
5.
添加一個 HTML 文本框，其 id 為“txtCustomerName”。
6.
在頁面的 Page_Load 方法中添加以下代碼（僅在使用 ASP.NET 服務器控件時才是必需的）：
ClientScript.RegisterOnSubmitStatement(cstype, Common.Events. ContextChanged, BuildRaiseEvent(Common.Events.ContextChanged));
7.
添加以下 private 方法（也是僅在使用 ASP.NET 服務器控件時才是必需的）：
private string BuildRaiseEvent(string topic) { StringBuilder sb = new StringBuilder(); sb.Append("window.external.FireEvent(\""); sb.Append(topic); sb.Append("\",0);"); return sb.ToString(); }
8.
雙擊第一個按鈕，在 onclick 事件中添加以下代碼：
window.external.FireEvent("ContextChangedEvent","Param1");
此代碼將觸發(fā) Web 頁面中的事件，并經(jīng)由 Smart Client Software Factory 轉為 Web 瀏覽器代碼，然后使用事件代理進入智能客戶端。
9.
在上一步的 onclick 事件處理程序之后添加以下代碼：
function EventBroker_Subscribe() { window.external.SubscribeEvent("ContextChangedEvent"); window.external.SubscribeEvent("CustomerContextChangedEvent"); } function EventBroker_ContextChangedEvent() { window.alert("上下文已更改事件：來自 Web 應用程序的問候"); }
通過 Subscribe 事件處理程序，智能客戶端可將何時設置事件訂閱告訴給 Web 頁面（通常在 Web 頁面將其自己載入瀏覽器控件后）。接下來，Web 頁面觸發(fā)并返回到主機，然后調(diào)用 SubscribeEvent（Web 頁面要訂閱的事件）。這樣，只要觸發(fā)該事件，CAB 中的所有全局事件就會從智能客戶端流動到 Web 頁面。這在 JScript 的 EventBroker_XXX 事件處理程序中捕捉。
10.
添加以下 JScript 函數(shù)：
function EventBroker_CustomerContextChangedEvent(eventData) { document.getElementById(‘txtCustomerName‘).value = eventData.Name; }
這顯示如何將事件數(shù)據(jù)從智能客戶端傳遞到 Web 頁面以及如何在 Web 頁面中使用這些數(shù)據(jù)。
步驟 2：創(chuàng)建 Web 模塊 要創(chuàng)建 Web 模塊，請首先右鍵單擊解決方案，然后選擇“Add”（添加）|“CompositeUI”|“Module”（模塊）。在“Add New Project”（添加新項目）對話框中，指定您自己的模塊名稱?，F(xiàn)在，單擊“OK”（確定），選擇“Shell”（外殼）項目，然后單擊“Finish”（完成）。
您會發(fā)現(xiàn)已創(chuàng)建了許多新項。一個新的 Web 模塊項目已添加到解決方案中。必需的引用（包括 CAB 和 Smart Client Software Factory 庫引用）已添加到該 Web 模塊項目中。已在新項目中創(chuàng)建了 WorkItems 文件夾，并在該項目中創(chuàng)建了 ModuleInit.cs 文件和類。
步驟 3：新建 WorkItem 新建 WorkItem 相當簡單。首先右鍵單擊剛創(chuàng)建的模塊中的 WorkItems 文件夾，然后選擇“Add”（添加）|“CompositeUI”|“WorkItem”。將名稱更改為 WebWorkItem.cs。選擇“Shell”（外殼）項目并單擊“Finish”（完成）按鈕。
此時，您將發(fā)現(xiàn)已創(chuàng)建了 WebWorkItem.cs 文件和類。此外，還為 CAB 和 Smart Client Software Factory 添加了 using 指令和必需的引用。
在 ModuleInit 類的 Load 中，添加以下代碼：
WorkitemCatalog.RegisterWorkItem<WebWorkItem>();
并將以下 using 指令添加到 ModuleInit.cs 文件的頂部：
using WebModule.WorkItems.WebWorkItem;
步驟 4：新建視圖 此步驟解決 Web 頁面和智能客戶端應用程序（在本例中為 Web 模塊）之間的數(shù)據(jù)交換。
1.
右鍵單擊 WebWorkItem 文件夾。
2.
選擇“Add”（添加）|“CompositeUI”|“View…”（視圖…）
3.
將名稱更改為 WebView，然后單擊“Finish”（完成）按鈕。這將創(chuàng)建 IWebView 接口、WebPresenter 類和 WebView usercontrol。它們用于實現(xiàn)在整個 Smart Client Software Factory 中使用的典型 MVP 模式。
4.
轉到 WebWorkItem 類，然后添加以下代碼：
public void ShowInView(IShellView view) { WebView webView = this.Items.AddNew<WebView>(); view.MainWorkspace.Show(webView); }
這會將 WebView（一個智能部件）添加到工作項“智能部件”集合的項集合中，并在工作項啟動時顯示該智能部件。
5.
在設計器模式中打開 WebView UserControl。
6.
從 Smart Client Software Factory 添加 Microsoft.Practices.SmartClient.Web.WebView 控件。
7.
將 Microsoft.Practices.SmartClient.Web.WebView 控件的 Url 屬性設置為您剛創(chuàng)建的測試 Web 頁面。
8.
轉到 WebWorkItem.cs 文件并添加以下 using 指令：
using Microsoft.Practices.SmartClient.UI.Themes;
9.
打開 WebPresenter 類并添加以下代碼：
[EventSubscription(Common.Events.ContextChanged, Thread=ThreadOption.UserInterface)] public void OnContextChange(object sender, EventArgs e) { System.Windows.Forms.MessageBox.Show( _ "上下文已更改：來自豐富 UI 組件的問候"); }
這由 Web 頁面觸發(fā)，通過 CAB 事件代理轉換為 WebView 代碼。
10.
添加以下 using 指令：
using Microsoft.Practices.CompositeUI.EventBroker;
11.
打開 IWebView 接口并添加以下代碼：
event WebBrowserDocumentCompletedEventHandler DocumentCompleted;
12.
打開 WebPresenter 類并添加
圖 4 中所示的代碼。這允許 Smart Client Software Factory 通過綁定訂閱響應 Web 頁面加載。加載 Web 頁面時，觸發(fā) CustomerContextChangedForWebPage 事件。將通過事件代理以 CustomerContextChanged（在 JavaScript 中）形式將其通知給 Web 頁面。這是在從智能客戶端啟動 Web 模塊時，上下文或信息從智能客戶端流動到 Web 頁面的作用，它允許任何 Web 應用程序在響應加載時顯示來自智能客戶端的任何信息。請注意，發(fā)送過程中的覆蓋操作并非必要，只是在加載特定事件時引發(fā)該事件。
13.
添加以下 using 指令：
using System.Threading; using System.Security.Principal; using Microsoft.Practices.CompositeUI.Utility;
14.
將以下代碼添加到 WebView 類（IWebView 實現(xiàn)）：
public event WebBrowserDocumentCompletedEventHandler DocumentCompleted { add { this.webView1.DocumentCompleted += value; } remove { this.webView1.DocumentCompleted -= value; } }
步驟 5：在與外殼應用程序相同的目錄中構建和測試 Solution Place WebModule.dll，并將該模塊添加到 ProfileCatalog.xml，以便 CAB 模塊加載程序服務能夠加載它。
最后，按照傳遞消息時所使用的同一模式，使用事件代理將其傳遞到其他模塊。像啟動任何其他 Web 模塊一樣來啟動此 Web 模塊?，F(xiàn)在，所有全局事件都應從智能客戶端流動到 Web 模塊，然后再流動回智能客戶端。
返回頁首對未來的展望
在我的樣例中，討論如何通過文檔對象模型 (DOM) 將 JavaScript 的一個小塊傳送回托管應用程序。這是使得基于 HTML 的操作窗格能夠訪問 XML 文檔的 DOM 時，InfoPath? 所使用的一項技術。
對于現(xiàn)有的基于 Web 的應用程序而言，這種方法相對來說具有一定的侵略性。它需要更改 Web 應用程序，重新編譯該應用程序，然后再對其進行重新部署。讓我們想像一下存在這樣一種攻擊性較小的方法：它允許任何智能部件將必要的集成代碼注入到 HTML 頁面的 DOM 中，在運行時而不是在編譯時執(zhí)行綁定。當然，還需要執(zhí)行一定的關于安全影響的嚴格審查。還要必須將其他功能添加到 Smart Client Software Factory 的事件代理中，以便在智能客戶端上下文和 HTML 頁面元素之間映射技術。
企業(yè)就緒模塊的未來是值得期待的。想像一下基于 Windows Workflow Foundation 的工作流模塊，它會為基于桌面的工作流方案提供一個全新的托管體系結構。工作流會立刻集成到由集成式桌面托管的現(xiàn)有應用程序中，為信息工作者提供另外一個能夠做出決策的集成載體以及一個結構化的任務列表外觀。那么，是否能夠通過一組工作流模塊將整個解決方案重構為耦合在一起的服務島呢？
這一體系結構正在研發(fā)中，而且必須不斷地將平臺的新功能包括在該體系結構中。持久性是企業(yè)級解決方案體系結構的真正測試之一。由 Windows Vista? 引入的新功能無疑會對我們?nèi)绾慰紤]解決方案方法帶來挑戰(zhàn)，而集成式桌面恰好利用了所興起的新功能。
Christian Thilmany 是一位技術架構師，在體系結構的設計、開發(fā)和咨詢方面擁有超過 16 年的經(jīng)驗，曾為各種財富 500 強企業(yè)提供咨詢服務。在 Microsoft，他擅長于集成、門戶以及智能客戶端模式和技術。
Jim Keane 是一位技術總監(jiān)，在德克薩斯州奧斯汀市工作。他曾有 20 多年的計算機行業(yè)架構師的經(jīng)歷，在小型企業(yè)、航空航天、半導體、保險和過程控制系統(tǒng)等領域具有豐富經(jīng)驗。
