設計複合應用程式：設計模式

本文學習在開發複合應用程式時如何識別並優化設計模式。

複合應用程式是面向服務架構（SOA）和上下文協作策略（contextual collaboration strategy）中的關鍵要素。當今市場競爭日趨激烈，企業必須快速響應不斷變化的使用者需求，而複合應用程式可以為企業提供業務靈活性。複合應用程式由一些使用者介面元件集合而成，這些元件通過彼此鬆散耦合支援元件間通訊。

元件可以在多個複合應用程式之間實現重用。將多種技術整合到單個應用程式中可以帶來顯著的業務價值。這提供了更好的靈活性，使企業能夠保護和擴充套件其現有資產，並允許企業使用應用程式快速且經濟有效地響應新出現的業務需求，這些應用程式比起在多個應用程式開發環境來說要容易建立得多。

這種鬆散耦合的複合應用程式架構還能使不同位置的各個團體利用彼此的工作成果並進行互操作。例如，某個部門可能正在為公司開發財務應用程式，而另一個小組則在開發潛在客戶跟蹤應用程式。複合應用程式的設想就是將潛在客戶跟蹤應用程式中的某些元件新增到財務應用程式中，從而能夠在財務上下文中檢視有關的資產檢視。類似地，潛在客戶跟蹤應用程式也可以合併來自財務應用程式的元件，從而在資產上下文中提供財務資訊。隨著企業開發的複合應用程式越來越多，整合已成當務之急。整合的目標就是實現整體作用大於個體作用之和。

IBM WebSphere Portal 開發人員已經非常熟悉複合應用程式模型。這種方法已經被擴充套件到 IBM Lotus Notes V8 中，使 Lotus Notes 開發人員能夠將 Lotus Notes 應用程式作為複合應用程式中的一個或多個元件。IBM Lotus Domino Designer 實現了進一步擴充套件，可以利用屬性代理並提供更加直觀的使用者環境。Lotus Notes V8 還支援包括 Eclipse 元件。複合應用程式可以將任何 Lotus Notes 和 Eclipse 元件組合在一起。這些元件可以組合在同一個使用者介面（UI）中，即進行介面（on-the-glass）整合，或者進行擴充套件以使用屬性代理，從而實現元件之間的互操作。可以使用 Composite Application Editor 或者 WebSphere Portal Application Template Editor 來定義複合應用程式。

複合應用程式的元件開發不同於傳統的 Eclipse 或 Lotus Notes 應用程式開發。複合應用程式需要建立具有足夠靈活性的元件，以便日後在部署到應用程式中時不需要進行大量重複工作。本文將討論在設計此類元件時需要用到的方法以及此過程採用的最佳實踐。

先決條件

本文要求讀者熟悉 IBM Lotus Notes 的複合應用程式，因此回顧 IBM Lotus Domino Designer Help 中有關複合應用程式的章節將非常有幫助。

您還應該回顧 developerWorks Lotus 文章 “IBM Lotus Notes V8 中的 Lead Manager 應用程式：概述” 和 “設計複合應用程式：元件設計”，其中介紹了有關元件設計的高階內容。這些文章討論了以域為中心的元件和上下文域元件，它們本身都是元模式。

開發模式

在開發過程中，我們經常使用類似的方法解決相似的問題，這種思想得到了很好的推廣。從早期的應用程式到物件導向程式設計，人們發現，在很多環境中，按照模式完成工作非常有效；換句話說，就是為很多應用程式中的常見問題提出通用的解決方案。複合應用程式的設計和開發也是如此，並且，本文將探討在這方面有幫助的模式。

為了使內容更有條理，我們將模式的型別分為不同的類別：

• 定義常用元件型別的模式
• 根據元件佈局和互操作方式定義元件集合的模式
• 定義應用程式或整體設計方式的模式，可用於構建整個複合應用程式或複合應用程式套件

元件模式

本節描述各種常見的元件型別。

選擇元件

選擇元件（selection component）允許值跨越多個資訊域。例如，一條出差請求提交可能包括一個引用了 Human Resources 記錄的員工編號，或者包含一個識別會計程式包中控制中心的成本中心。出差請求應用程式在其業務邏輯中跟蹤這些值，僅供參考，且業務邏輯中會與其他資訊域發生交叉。在 UI 層，值欄位如果不是由這個資訊域定義，那麼通常只是使用者必須填寫的輸入框，這就有可能產生輸入錯誤。

每個應用程式都可針對其域內的資訊建立一些選擇元件。由於應用程式具有其域內的所有資訊，因而可以為使用者提供所有適當的方法供選擇。這是一種典型的上下文域元件，在 developerWorks Lotus 文章 “設計複合應用程式：元件設計” 中曾討論過。在上面的例子中，Human Resources 應用程式會生成一個選擇元件用於選擇員工，可以根據姓名、電子郵件、電話、位置或應用程式跟蹤的任何其他欄位進行搜尋。元件輸出可以是這些欄位中的任意一個，也可以是用於出差請求的員工編號。

可以使用下面任一種方法呈現元件：

• 通過 UI 形式呈現。UI 位於應用程式頁面的邊緣或指示板中，主要記錄就是在這裡複合的。複合區域的編輯欄位被繫結到選擇元件。如果值是已知的，只要將其輸入編輯器即可；否則，可使用選擇元件進行選擇和搜尋，之後將得到的值填充到編輯器中。
• 通過具有小型 UI 的不可見元件呈現。除了處理和傳播有關的索引值時用到的屬性和操作之外，還有另一個值用於通知元件顯示其 UI。這是一個彈出式對話方塊，其中包含元件要呈現的相同的搜尋選項。雖然這要求在傳送元件上使用 Lookup 按鈕（因此耦合鬆散度降低），但是可以更有效地使用 UI。搜尋皮膚只有在需要時顯示。

資訊元件

資訊元件（information component）提供有關單個資料記錄的詳細資訊。它可以是詳細的完整檢視，顯示記錄中的所有資料元素，也可以是僅顯示高階資訊的摘要。它還可以針對記錄中的特定資訊子集。在 developerWorks Lotus 的 Lead Manager 樣例應用程式 中，有很多用於 Companies 和 Leads 的資訊元件。其中每個資訊元件都有一個包含完整 Lotus Notes 表單的 Detail 元件，以及僅包含基本資訊的 Summary 元件。

和選擇元件一樣，也可以為資訊元件設定最小化的頁面顯示。啟用元件之後，可以通過程式設計或 UI 建立一個包含資訊的彈出對話方塊。這可以節省螢幕中的操作區域，同時不會損失功能。這類彈出視窗經常用於 Lead Manager 樣例中。

啟動程式元件

啟動程式元件（launcher component）是另一種上下文域元件。它並沒有通過新增資訊來增強包含應用程式（containing application），相反，它新增了功能性。通過連線，可從包含應用程式的上下文中檢索資料元素並顯示針對這些資訊的處理選項以及自身域的處理步驟。它可以顯示自己的 UI 供使用者從中選擇操作，也可以接受某種操作。這允許另一個以域為中心的元件命令它執行類似於彈出式選擇元件的操作。雖然耦合度沒有達到理想的鬆散度，但是實現了更加緊密的 UI。如果元件能夠通過直接操作或使用者互動而工作，那麼可以由應用程式裝配程式作出決策。

例如，未來版本的 Lead Manager 應用程式要求將潛在客戶資訊域與郵件和即時訊息域聯絡起來。郵件元件公開可以編寫郵件的操作，當該操作被觸發時，將啟動一個新的郵件備忘錄。當檢視潛在客戶或公司資訊記錄時，UI 中的某個選項可以將郵件訊息傳送給潛在客戶或公司的聯絡人。元件通過觸發與郵件元件的連線完成這一操作。通過類似的技術為您提供啟動即時訊息會話的選項。

由於很多潛在客戶來源於郵件，所以您可以建立一個啟動程式元件，它處理很多屬性（這些屬性對應於針對新潛在客戶的輸入條目），並公開一個 Create Sales Lead 按鈕。當單擊這個按鈕時，將切換到潛在客戶應用程式，同時元件呼叫 UI 建立新的潛在客戶並使用可用資訊進行填充。可以在您的郵件模板（或與啟動點相關的其他資料庫）中部署這個元件，同時將當前選中的郵件資訊的 To 欄位連線到啟動程式元件的 Salesperson 屬性，將 From 欄位連線到 Customer 屬性。檢視郵件訊息時單擊 Create Sales Lead 選項，將顯示可建立新潛在客戶的 UI，其中已經預填了 Salesman 和 Customer 欄位。

計算元件

計算元件（calculation component）的功能是輸入一個或多個值後能夠生成一個或多個派生值作為輸出。它可以使用多種形式，包括簡單的一般性算術計算和上下文域查詢。在很多情況下，這些元件不具備互動式 UI。元件可以保持空白並置於應用程式中不引人注意的區域，或者用來顯示徽標或其他標誌。

以一個簡單的數學元件為例，它使用以逗號分隔的值列表作為輸入，並將這些值的總和作為輸出。如果您的列表元件能夠將一列資料作為一組值匯出，那麼該元件將被連線到求和（summation）元件，而將結果傳送回另一個元件以顯示總和。

計算元件的另一種表現是一種特殊形式的選擇元件。假設您有一個採購訂單應用程式。超過一定數量的採購必須徵得經理同意。訂單提交部分要求填寫經理的姓名和郵件地址。在此處需要使用選擇元件，但是使用者仍有可能選擇錯誤的經理人選。作為一種替代方法，您可以從員工資料庫應用程式中開發一個域上下文元件，它可以接受包含員工姓名的操作，然後釋出有關該員工的各種資訊。應用程式裝配程式隨後將經理資訊連線到表單的輸入部分。您甚至可以將表單的輸入欄位修改為計算欄位，從而防止使用者輸入錯誤。

除呈現資料以外，這些元件還可以呈現業務邏輯。在上文的例子中，假設每個員工的支出限度都不相同，並且還取決於內部制度（如地區）。財務資訊域的計算元件可以捕獲員工姓名並返回該員工的支出限度。採購應用程式中以域為中心的元件能夠實時檢查這個限額值，而不是等待後端程式對這個值進行標記。

這種元件的特殊形式可以處理資料型別轉換。為元件的屬性和操作定義強資料型別可以實現更加簡單和準確的應用程式裝配。某些情況下，您可能需要使用具有弱型別屬性和操作的通用元件。一個簡單的計算元件可以使用某種型別的操作併發布資料相同但型別不同的屬性。在部署時，可將這些實用元件部署為不可見或具有最小化 UI，並作為兩種不相容元件（例如，一個元件具有可以處理郵政編碼的操作併發布包含城市名和州名的字串）之間的格式轉換程式連線。

聚合元件

某些複合應用程式可能由一些頁面組成。可以通過由平臺提供並受 Composite Application Editor 支援的跨頁面連線（cross-page wires）在頁面之間維護簡單的應用程式上下文。當希望修改某個頁面上下文時，將通過跨頁面連線將一個屬性連線到另一個頁面中的某個操作。啟用這個屬性將導致頁面發生修改並將上下文傳遞給新的頁面。在更為複雜的場景中，僅僅使用單個項維護頁面以及將頁面轉換與上下文傳遞相結合並不能夠滿足需求。上下文需要跟蹤多個值，並且頁面轉換可通過使用其他使用者操作而發起。

聚合元件（aggregation component）是一種資料儲存元件。它為每個值維護多個具有對稱屬性和操作的值。當操作設定一個值後，將觸發相應的屬性。此外，當元件發現它所在的頁面變為可見時，它將觸發所有已知屬性。關鍵是元件為應用程式的所有例項維護單一的資料模型。也就是說，當置於多個頁面時，在某一頁面設定的值可以在另一個頁面中檢索到。

在使用聚合元件時，不能使用普通的方法直接連線元件之間的值。相反，具有上下文重要性的值將從第一個元件的屬性連線到聚合程式中的操作，然後再從聚合應用程式中相應的屬性連線到目標元件的操作。針對單個頁面執行的普通操作都遵循這一過程。對第一個元件作出的屬性修改通過聚合程式傳播到目標元件。但是在頁面轉換期間，當目標頁面可見時，聚合程式將釋出所有已知值。通過這種方法，當連線到聚合程式時，目標頁面上的所有目標元件將進行更新。

例如，某個銷售應用程式需要跟蹤當前公司、潛在客戶和銷售代表。其中一個頁面顯示公司細節，以及該公司的銷售代表列表。選擇銷售代表之後，將出現一個彈出式視窗，顯示有關該銷售代表的詳細資訊，如電話號碼和郵件地址。您可以選擇建立新的潛在客戶，這將顯示覆合應用程式中的另一個頁面。需要根據當前的設定值預填充公司名稱和相關的銷售代表欄位，但是，僅僅使用跨頁面連線無法實現這一目的。

為此，將在第一個頁面引入一個聚合元件。負責選擇公司和銷售人員的元件通過聚合元件確定連線路徑。隨後將同一聚合元件的另一例項放入第二個頁面，將在此頁面建立潛在客戶。接著，將當前公司和銷售人員的屬性連線到對應的輸入欄位中，當聚合元件檢測到頁面發生切換時，它將觸發屬性並預填充表單。

其他元件模式

本系列下個月的文章將討論詳細的資訊元件、編輯模式元件、摘要元件、列表元件和受限列表元件。儘管本文所述內容針對 Lotus Notes 上下文，但是這些模式可以應用到任何形式的開發環境中。

佈局模式

本節將介紹各種佈局模式。

Radiating 指示板

複合應用程式可以向正在處理的流程上下文新增相關資訊；然而，您仍然要將注意力主要集中在中心工作上。可以使用某種模式來平衡這兩種需求，該模式頁面中主要活動使用的元件佔用中心區域。這些通常是以域為中心的元件，可以檢視、操縱和處理單條記錄或資料集合。

其他上下文元件佈置在螢幕的邊緣位置，可顯示中心操作的詳細資訊和上下文。這個指示板位於中心區域的兩側、底部，甚至可位於中心區域的頂部，您可以根據設計需求安排佈局。可以將元件組織在資料夾中，從而管理螢幕操作區域並提供豐富、可立即訪問的資訊，同時不會佔用大量空間。同樣，可以使用彈出式元件在需要時顯示最小化顯示的 UI，從而管理空間。

連線 radiating 指示板頁面十分簡單。通常，建立上下文的位置（例如使用者選擇、跨頁面連線或聚合元件）與主要的域中心元件之間存在資料來源連線。這些連線將進一步擴充套件到指示板，為需要索引的鍵提供顯示的資料。

Lead Manager 應用程式中的一些頁面就使用了這種佈局，例如 Sales Lead Details 和 Company Details（參見圖 1）。佔用螢幕中心區域的元件將詳細顯示目前持有焦點的主要記錄。指示板包含了一個附籤式資料夾，提供與該記錄相關的其他資訊集合。

圖 1. 公司細節

在只讀模式下單擊 Info 按鈕將顯示彈出式元件（參見圖 2）展示更多資訊。在編輯模式下，彈出式元件將變為選擇元件，協助實現複合。

圖 2. 彈出式元件顯示公司細節

列表頁面

列表頁面旨在顯示某一範圍內資料記錄的聚合資訊。頁面中心區域通常由列表或受限列表元件構成，提供各種方法排序或顯示資料記錄。作為補充，其他資訊元件對進行顯示和選擇的資訊摘取共性資訊。在 Help Desk 應用程式中，您可以在列表元件中檢視特定員工的通話記錄，而資訊元件可以列出所顯示通話的平均通話時間。在財務應用程式中，可以列出某一賬戶進行的交易，而摘要元件可以列出所瀏覽交易的總價值。

選擇頁面

選擇頁面是列表頁面的變體。在列表頁面中，檢視聚合資訊可以全面理解資訊集合。在選擇頁面中，也可以檢視聚合資訊，然後進一步聚焦特定資料元素。這樣，您的 UI 頁面可以將您導航到其他區域（例如 radiating 指示板）中顯示具體細節的頁面。

選擇頁面通常由一個或多個允許使用者選擇條件的選擇元件構成。受限列表元件根據這些條件檢視資料集。受限列表中的選擇或焦點狀態將進一步投影到資訊元件的指示板中，提供更多詳細資訊並指導作出選擇。當選擇好要進一步檢視細節的資料後，將啟用選擇，例如，單擊按鈕或雙擊滑鼠左鍵可設定上下文或切換到正確的頁面。如果上下文比較簡單，將通過一個跨頁面連線執行；否則，將使用一個聚合元件和一個頁面切換元件執行操作。

連線選擇頁面比連線 radiating 指示板頁面稍微複雜一些。選擇元件必須連線到受限列表，後者再連線到指示板元件。如果含有多個選擇器或多個列表，則可能需要多個並行連線，以確保在啟用相應控制後顯示正確的資料流。

注意：使用附籤式資料夾時需要稍加註意。例如，如果非附籤式資訊元件連線到附籤式受限列表，那麼這些列表不僅在選擇發生改變時需要傳播其選擇狀態，當選擇變為可見時也要執行相同的操作，從而確保資訊元件能夠正確顯示相關內容。

在 Lead Manager 應用程式中，Sales Leads 頁面（參見圖 3）使用 Selection Page 進行佈局。Lead Browser 元件位於螢幕的左側，可以顯示多個選擇模式。您可以列出各個公司（根據盈利規模、業務領域等排序並選擇）並從特定公司中列出潛在客戶。您還可以列出銷售人員以及各個銷售人員負責的潛在客戶。所有這些內容都提供給螢幕右側的受限列表，根據在 Lead 瀏覽器中選擇配置並確定潛在客戶狀態，受限列表元件將顯示處於待定和關閉狀態的潛在客戶。

當更新這些元件中的某個選擇時，螢幕底部的資訊元件將顯示所選擇的潛在客戶及其所屬公司的摘要資訊。如果雙擊某個潛在客戶，將通過跨頁面連線傳遞該潛在客戶的資訊並進行頁面切換，顯示關於該客戶的詳細資訊。

圖 3. Sales Leads 頁面

記錄顯示頁面

該頁面顯示某個特定記錄型別的詳細資訊。主要顯示區域展示目標記錄型別的詳細資訊。在指示板區域，將安排額外的元件來提供與資料記錄相關的補充資訊。

在 Lead Manager 應用程式中，Company Details 螢幕就按照這種模式佈局（參見圖 1）。螢幕中心區域顯示某條公司記錄的完整描述。指示板包含附籤式資料夾，其中的元件顯示該公司的潛在客戶、公司介紹、企業網站等內容。單擊 Info 按鈕將顯示包含更多資訊的彈出式元件（參見圖 2）。

記錄編輯頁面

該頁面類似於記錄顯示頁面，惟一不同的是可在此編輯目標記錄。此時沒有必要使用相關資料的指示板，因此此時記錄值並不完整或正在建立中。相反，指示板包含的元件用於幫助使用者實現記錄合成。

例如，您可以使用一個選擇元件對企業資料庫進行索引，而這個資料庫與需要輸入員工姓名的欄位相繫結；您可以檢視最近的郵件以編輯聯絡人欄位；還可以使用 Web 瀏覽器進行常規搜尋，將當前 Web 地址匯入到相應欄位中。

您可以根據自己的需要，建立既是記錄顯示頁面又是記錄編輯頁面的頁面。這樣可以始終以固定格式顯示記錄細節，但是，如果某些資訊元件只與只讀或編輯模式相關，那麼需要確保正確處理這些元件的啟用和可見性。

應用程式模式

本節將討論應用程式模式。

以資料為中心

以資料為中心的應用程式主要關注所管理的資料。可以通過從涉及的資訊域中選擇一些主要資料記錄進行設計。構建列表頁面顯示有關資料記錄集合的聚合資訊。可針對包含的記錄型別建立一個記錄顯示頁面，併為可進行建立或編輯的記錄型別建立記錄編輯頁面。這可以組織為一個樹形結構，其中列表頁面為樹幹，記錄頁面為樹葉。您可以使用內建的複合應用程式導航器切換頁面，使用聚合元件在進行頁面轉換時保持上下文。通過使用跨頁面連線啟用頁面並建立上下文，可以在導航時隱藏葉頁面。

Lead Manager 樣例應用程式在設計時主要依據了這一模式。因為可以進入編輯模式，所以您可以以列表（例如選擇頁面）或個體（例如記錄顯示頁面）形式檢視潛在客戶、公司、聯絡人、討論和合同。對於可以向下展示更多細節的區域，可以進行頂級訪問。還提供了交叉連結支援，從而能夠從某個詳細的上下文移至另一個與之對應的上下文中。在 Lead Manager 樣例中，在 Leads/Companies、Discussions、Contracts 和 Contacts 等不同的應用程式域中實現了交叉連結。

以流程為中心

以流程為中心的應用程式側重於某一任務而非具體的資料。根據面向某一員工角色的工作流場景，您將在應用程式中建立一系列頁面，員工可通過這些頁面完成分配的任務。例如，在一個管理廣告建立的應用程式中，工作流引導您完成從確定目標和定義到尋找代理、管理並批准代理，以及最終完成歸檔等各個階段工作。

無論何種情況，您可以具有相同的資料記錄集。當確定目標和定義之後，可將廣告活動記錄連結到討論區域或活動組，參與者從此處確定廣告活動內容。在尋求代理階段，可以使用一些元件將之前定義的目標提煉為關鍵字以進行搜尋，或者使用欄位元件列出關於以前合作的代理的反饋。在管理專案時，可能需要使用郵件資料庫跟蹤信件往來並管理退出。最後，在歸檔階段，需要使用過去活動的合計清單或由這些廣告活動產生的效益。

在以流程為中心的應用程式中，您具有一組專門針對當前任務和主要記錄的工作流狀態的頁面。不同角色的員工只能看到與之相關的頁面，這可以通過在 WebSphere Portal 部署的應用程式中實現，方法為在複合應用程式的頁面中設定許可權。這種方法不能用於 NSF 部署的複合應用程式中；因此，最簡單的方法是為每個角色建立不同的複合應用程式，其中只包含各個角色所需要的頁面。

事實上，複合應用程式的一大優點就是隻需執行較少的工作就可實現針對特定區域的不同應用程式。通過重用元件，不必進行大量重複開發和重新部署就可獲得生產力得到增強的應用程式。

如當前所定義的一樣，Lead Manager 樣例使用了以資料為中心的模式。此外，通過重用 Lead Manager 樣例中的大量元件，可以建立一個全新的複合應用程式來利用以流程為中心的應用程式模式 —— 例如，管理與合同相關的流程。潛在客戶所有者為某一特定潛在客戶建立合同之後，法律部門將針對合同進行審查，然後再由使用者過目。複合應用程式可以定義這個流程並提供幫助。

聚合模型

聚合應用程式可以將多個流程聚集在一起，但是大多數屬於介面整合。它的優點是將使用者所需的工具集中到一個位置從而方便工作。這種整合程度較輕，只需少量互操作，但是開發迅速且簡單，可以作為使用者工具整合的初級階段。隨著瞭解程度加深，可以使用聚合應用程式將複合應用程式的優勢擴充套件到廣泛的使用者範圍中。

您可以從使用者那裡獲得反饋，瞭解在哪些位置執行互操作有意義並對流程有幫助，從而進一步細化方法。您可以從封裝完整應用程式的單個元件入手，並根據使用者需求將這個元件拆分為多個能夠在任何位置呈現的更小的元件。

聚合模式最早用於 Lead Manager 樣例應用程式的開發階段。使用者與 4 種應用程式進行互動：Leads/Companies、Discussions、Contracts 和 Contacts。通過將獨立的 NSF 應用程式整合為單個多頁面複合應用程式，您將體會到複合應用程式的優點。

結束語

本文描述的模式僅僅是所有複合應用程式和元件模式的其中一小部分。這些模式可以按照元件、佈局和應用程式以及角色分類，可能並不完全適用。最好全面瞭解所有模式類別，理解其他人如何使用元件和裝配應用程式。

在開發 Lead Manager 樣例和其他複合應用程式時，我們發現其中很多模式都非常有用。其中一些模式可能看上去十分明顯，但是，識別各種開發模式有助於您建立具有一致感官以及依賴經過測試的技術和元件的應用程式。

在研究複合應用程式時，可能會發現可以使用其他方式解決遇到的問題。記錄這些方法，尋找成功解決相同問題的其他方法，並開始建立屬於您自己的模式庫。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14751907/viewspace-404346/，如需轉載，請註明出處，否則將追究法律責任。