Anywhere you go, let me go too

關於部落格
對人海闊天空,做事仔細周密
----------------------
因為改了平台後...覺得不是很好用....所以有另外......(評估中)
http://blog.xuite.net/king119wang/myskills
  • 32543

    累積人氣

  • 2

    今日人氣

    0

    訂閱人氣

設計應用程式和服務

.NET 的應用程式架構:設計應用程式和服務
設計應用程式或服務的元件

2002 年 12 月

摘要:本章討論分散式 .NET 應用程式或服務之中不同種類的元件,並描述設計這些元件的最佳實例。

第 1 章說明由多個元件組成應用程式或服務的方式,其中每個元件都執行不同種類的工作。每個軟體解決方案都包含類似種類的元件,不論該方案所解決的是哪種特定的商業需求。例如,大部分應用程式所包含的元件,都可用來存取資料、封裝商業規則、處理使用者互動等作業。識別在分散式軟體解決方案中常見的元件種類,有助於建立應用程式或服務設計的藍圖。

本章內容

本章包含下列小節:

元件類型

對根據分層的元件模型而建立的商業解決方案進行檢視,可以發現有數種常見的元件類型。圖 2.1 中詳細地顯示了這些元件類型。

注意事項:Component 這個詞是指整個解決方案的一個片段或部分。這包括已編輯的軟體元件,例如 Microsoft .NET 組件以及其他的軟體製品,例如網頁和 Microsoft® BizTalk® Server Orchestration 排程。

雖然圖 2.1 中所示的元件類型清單並不完整,但卻代表大部分分散式解決方案中常見的軟體元件類型。本章的其他部分將詳細說明這些元件類型。

ms978348.f02apparch01(zh-tw,MSDN.10).gif

圖 2.1 零售範例情況中的元件類型

在範例案例設計中,可以識別出下列的元件類型:

  1. 使用者介面 (UI) 元件:大部分的解決方案都需要為使用者提供與應用程式互動的方式。在此零售應用程式的範例中,客戶可透過網站檢視產品並傳送訂單,而根據 Microsoft Windows® 作業系統而建立的應用程式,則可供業務代表輸入打電話給公司訂購的客戶訂單資料。使用者介面的實作,是透過 Windows Form、Microsoft ASP.NET 網頁、控制項,或任何其他呈現和格式化使用者資料的技術,及擷取和驗證使用者所提供資料的技術而達成。
  2. 使用者處理序元件:在許多情況下,使用者都會根據可預測的處理序與系統互動。例如,零售應用程式中所實作的產品資料檢視程序,會讓使用者從可用產品的類別清單中選取類別,然後再於所選類別中選擇個別產品來檢視其詳細資料。同樣地,當使用者選購產品時,互動作業也會遵循可預測的處理序向使用者收集資料,首先使用者提供要選購產品的詳細資料,然後提供付款詳細資料,最後再輸入詳細的運送資料。為了同步化及協調這些使用者互動作業,使用個別的使用者處理序元件驅動整個處理流程會很有用。如此一來,處理流程和狀態管理邏輯就不會採用硬式編碼的方式,寫在使用者介面項目內,而相同的基本使用者互動「引擎」,也可由多個使用者介面重複使用。
  3. 商業工作流程:在使用者處理序收集了所需的資料後,這些資料便會用來執行商業處理流程。例如,在產品、付款和運送的詳細資料傳送到零售應用程式後,就可以開始進行收款和安排運送等處理流程。許多商業處理流程都包含多個步驟,必須以正確且經過協調的順序執行。例如,零售系統需要計算訂單的總值、確認信用卡的詳細資料、處理信用卡的付款,並安排貨物的運送。完成這個處理流程的時間並不確定,所以必須管理所需的工作和執行這些工作所需的資料。商業工作流程會定義及協調長期執行且包含多個步驟的商業處理流程,且可以使用 BizTalk Server Orchestration 等商業處理流程管理工具實作。
  4. 商業元件:不論商業處理流程是由單一步驟或經過協調的工作流程所組成,應用程式都可能需要實作商業規則及執行商業工作的元件。例如,在零售應用程式中,您需要實作計算訂購商品總價格以及正確運送費用的功能。商業元件會實作應用程式的商業邏輯。
  5. 服務代理程式:當商業元件需要使用外部服務所提供的功能時,您可能需要提供程式碼以管理與該特定服務通訊的語意。例如,前述的零售應用程式商業元件可以使用服務代理程式,以管理與信用卡授權服務的通訊,並使用另外的服務代理程式處理與信差服務的交談。服務代理程式會將呼叫各種服務的方法與應用程式區隔開來,並提供額外的服務,例如在服務所顯露的資料格式與應用程式需要的格式之間,進行基本的對應。
  6. 服務介面:如果要將商業邏輯顯露為服務,則必須建立服務介面,以支援不同客戶所需的通訊合約 (訊息通訊、格式、通訊協定、安全性、例外等)。例如,信用卡授權服務必須顯露服務介面,以描述服務所提供的功能和呼叫該服務所需的通訊語意。服務介面有時也稱為「商業外貌」。
  7. 資料存取邏輯元件:大部分的應用程式和服務都需要在商業處理流程中存取資料存放區。例如,零售應用程式需要從資料庫擷取產品資料,將產品的詳細資料提供給使用者,也需要在使用者下訂單時,將訂單詳細資料插入資料庫。將存取資料的必要邏輯,區隔為不同層級的資料存取邏輯元件,是有其必要性的。這麼做可以集中資料存取功能,並簡化其設定及維護工作。
  8. 商業項目元件:大部分的應用程式都需要在元件之間傳遞資料。例如,在零售應用程式中,必須將產品清單從資料存取邏輯元件傳送到使用者介面元件,為使用者顯示產品清單。這些資料是用來代表實際的商業項目,例如產品或訂單。在應用程式內部使用的商業項目,通常是資料結構,例如 DataSet、DataReader 或「可延伸標記語言」(XML,Extensible Markup Language) 資料流,但這些項目也可以用自訂的物件導向類別來實作 (這些類別代表應用程式必須使用的實際項目,例如產品或訂單)。
  9. 安全性、操作管理與通訊的元件:您的應用程式可能還會使用元件來執行例外管理、授權使用者執行特定工作,以及與其他服務和應用程式通訊等。有關這些元件的詳細說明,請參閱第 3 章< 安全性、操作管理與通訊原則>。

應用程式和服務的一般設計建議

在設計應用程式或服務時,應該考慮下列建議:

  • 識別應用程式所需的元件類型。某些應用程式不需要特定的元件。例如,不需要與其他服務整合的小型應用程式可能不需要商業工作流程或服務代理程式。同樣地,應用程式如果只有一個具有少數項目的使用者介面,就可能不需要使用者處理序元件。
  • 設計特定類型的元件時,請使用單一或少量的設計模型,盡可能保持元件的一致性。這麼做有助於所有開發團隊在設計和實作時,保有元件可預期並易於維護的特性。在某些情況下,由於技術環境的因素 (例如,如果同時要開發 ASP.NET 和 Windows 的使用者介面),可能很難維持邏輯性的設計;不過,您應該在個別環境中努力維持設計的一致。在某些情況下,可以對所有使用類似模式的元件 (例如資料存取邏輯元件) 採用基底類別。
  • 請在選擇實體的發佈界限前,了解元件之間如何通訊。選擇遠端通訊的介面時,最好選擇範圍較大、連接度較鬆散的通訊方式,而非頻繁的通訊。
  • 用來資料交換的格式,與應用程式或服務內部所用的格式要一致。如果必須混用不同的資料代表格式,格式的種類越少越好。例如,為了增快在 Microsoft ASP.NET 中轉譯資料的速度,您也許會使用 DataReader 從資料存取邏輯元件傳回資料,而在商業處理流程中則使用 DataSet。但是請小心,在同樣的應用程式中混用 XML 字串、DataSet、序列物件、DataReader 及其他格式,會增加應用程式在開發、擴充和維護上的難度。
  • 請盡可能將強制執行原則 (例如安全性、操作管理與通訊限制) 的程式碼,與應用程式的商業邏輯加以區隔。嘗試使用為與原則相關的功能 (例如發佈例外、授權使用者等) 提供「單行程式碼」存取的屬性、平台應用程式開發介面 (API,Application Programming Interface) 或公用程式元件。
  • 一開始就決定要強制執行何種層級區隔。在層級區隔嚴謹的系統中,層級 A 的元件不能呼叫層級 C 的元件,而一定會呼叫層級 B 的元件。在層級區隔較寬鬆的系統中,某層級的元件所呼叫的元件,不一定位於緊接其下的層級中。在所有狀況中,都請避免往上游呼叫及相依的情況,也就是層級 C 叫用層級 B。您可以實作較為寬鬆的層級區隔,以避免接近底層的層級變化時,在所有層級中產生連鎖效應;或避免元件僅傳遞呼叫給底下的層級。

設計介面層級

介面層級包含使用者與應用程式互動時所需的元件。最簡單的介面層級包含使用者介面元件,例如 Windows Form 或 ASP.NET Web Form。如果要執行較為複雜的使用者互動作業,可以設計使用者處理序元件,以協調使用者介面項目並控制互動作業。當使用者互動作業遵循可預期的步驟流程 (例如使用精靈完成工作) 時,使用者處理序元件特別有用。圖 2.2 顯示介面層級中的元件類型。

ms978348.f02apparch02(zh-tw,MSDN.10).gif

圖 2.2 介面層級

以零售應用程式為例,所需的使用者介面有兩種:一個介面是客戶使用的電子商業網站,另一個則是業務代表所用的 Windows Forms 應用程式。兩種使用者都會透過這些使用者介面執行類似的工作。例如,這兩種使用者介面都提供以下功能:檢視提供的產品、將產品加入購物車,以及在結帳處理流程中指定付款詳細資料。您可將這項處理流程區隔為個別的使用者處理序元件,使應用程式更易於維護。

設計使用者介面元件

實作使用者介面的方式有很多種。例如,零售應用程式需要 Web 使用者介面和 Windows 使用者介面。其他種類的使用者介面則包括語音呈現、文件程式、行動用戶端應用程式等。使用者介面元件管理與使用者之間的互動。這些元件會顯示資料、從使用者處取得資料,並解譯使用者根據商業資料所做行動的事件、變更使用者介面的狀態,或協助使用者進行工作。

使用者介面通常包含頁面或表單上的數個項目,這些項目會顯示資料並接受使用者輸入。例如,Windows 應用程式可以包含 DataGrid 控制項 (顯示產品類別清單) 以及命令按鈕控制項 (指示使用者想要檢視所選類別中的產品)。當使用者與使用者介面項目互動時,會引發事件而呼叫控制函數中的程式碼。控制函數則接著呼叫商業元件、資料存取邏輯元件或使用者處理序元件以實作想要的動作,並擷取任何要顯示的必要資料。之後,控制函數會正確地更新使用者介面項目。圖 2.3 顯示使用者介面的設計。

ms978348.f02apparch03(zh-tw,MSDN.10).gif

圖 2.3 使用者介面設計

使用者介面元件功能

使用者介面元件必須顯示資料給使用者、擷取並驗證使用者輸入的資料,並解譯使用者想要對資料執行的操作。此外,使用者介面還需要篩選可用的動作,讓使用者只能在特定時間時執行適當的操作。

使用者介面元件:

  • 不會初始化、參與或為交易撥款。
  • 如果需要顯示目前使用者處理序元件的資料或對其狀態進行作業,則擁有對該元件的參考。
  • 可以封裝檢視功能和控制器。

在接受使用者輸入時,使用者介面元件會:

  • 為工作提供視覺提示 (例如工具提示)、驗證和正確的控制項,從使用者處取得資料並協助其輸入。
  • 從使用者處擷取事件並呼叫控制函數,告訴使用者介面元件變更顯示資料的方式;您可以在目前的使用者處理序上初始化動作,或變更目前使用者處理序的資料來進行上述作業。
  • 限制使用者可以輸入的輸入類型。例如,[數量] 欄位可以限制使用者只能輸入數值。
  • 執行資料輸入驗證,這項作業可以藉由限制能夠輸入特定欄位的數值範圍,或者確定是否輸入了必要資料等方式執行。
  • 為使用者控制項所提供的資訊執行簡單的對應和轉換,對應並轉換為基礎元件執行工作時所需的數值 (例如,使用者介面元件顯示產品名稱,但將產品 ID 傳遞給基礎元件)。
  • 解譯使用者的舉動 (例如拖放操作或按按鈕等) 並呼叫控制函數。
  • 可以使用公用程式元件進行快取。在 ASP.NET 中,可以為使用者介面元件的輸出指定快取,以避免每次都要重新轉譯輸出。如果應用程式包含的視覺項目代表不常變化、也不會用於交易情況的參考資料,而且這些項目由數量龐大的使用者所共用,則應該將這些項目放入快取。視覺項目如果由眾多使用者共用,且代表不常變化、也不用於交易情況的參考資料,便應該快取。
  • 可以使用公用程式元件進行分頁。將冗長的資料清單以分頁顯示是常見的做法,在 Web 應用程式中更是如此。用「輔助程式」元件追蹤使用者目前所用的頁數很尋常,這麼做可以叫用資料存取邏輯元件的「分頁查詢」函數,用正確的數值顯示頁面大小和目前的頁面。分頁可以在不與使用者處理序元件互動的情況下進行。

在呈現資料時,使用者介面元件:

  • 從應用程式的商業元件或資料存取邏輯元件取得資料並加以呈現。
  • 執行數值的格式化 (例如適當地格式化日期)。
  • 對呈現的資料執行本土化工作 (例如,以使用者地區設定的適當語言,使用資源字串顯示格線中的欄標題)。
  • 通常會呈現有關商業項目的資料。這些項目通常是從使用者處理序元件取得,但也可以從資料元件取得。如果已經有項目存在,則 UI 元件可能會將顯示的資料繫結至項目元件的正確屬性和集合,以呈現資料。如果您是以 DataSet 的方式管理項目資料,則這項作業很簡單。如果已經實作了自訂項目物件,則可能需要實作額外的程式碼,幫助資料繫結。
  • 為使用者提供狀態資訊,例如指示應用程式的狀態是「已中斷連線」或「已連線」。
  • 可以根據使用者喜好設定或所用的用戶端裝置種類,自訂應用程式的外觀。
  • 可以使用公用程式元件提供復原功能。許多應用程式都需要讓使用者復原特定的操作。其執行方式通常是藉由為特定的資料項目或全部項目保留固定長度的「舊值-新值」資料堆疊。當操作涉及商業處理流程時,就不能將補償作業顯露為單純的復原函數,而要作為明確的操作。
  • 可以使用公用程式元件提供剪貼簿功能。在許多 Windows 應用程式中,提供數值以外的剪貼簿功能很有用:例如,您可以讓使用者剪貼完整的客戶物件。這類功能通常是藉由將 XML 字串放入 Windows 的剪貼簿中實作;如果是其他應用程式特有的剪貼簿,則由全域物件實作 (全域物件會將資料保存在記憶體中)。

Windows 桌面使用者介面

Windows 使用者介面通常是在需要中斷連線、離線等功能或大量使用者互動,甚至與其他應用程式的使用者介面整合時使用的。Windows 使用者介面可以利用各種狀態管理和保存性選項,並可以存取本機的處理功能。有三種主要的獨立使用者介面:「完整」的 Windows 應用程式、包含內嵌 HTML 的 Windows 應用程式,以及可以在主應用程式中的使用者介面內使用的外掛應用程式:

  • 以 Windows Form 建立的「完整」桌面/Tablet PC 使用者介面

    建立 Windows 應用程式涉及使用 Windows Form 和控制項建立應用程式,其中應用程式幾乎提供所有的資料轉譯功能。這可以讓您大幅掌控使用者經驗,並對應用程式的外觀及操作進行全面掌控。不過,這會使您受制於用戶端平台,且必須為使用者部署應用程式 (就算應用程式的部署方式是透過 HTTP 連線而下載)。

  • 內嵌 HTML

    您可以選擇使用 Windows Forms 實作整個使用者介面,或者可以在 Windows 應用程式中使用其他的內嵌 HTML。內嵌 HTML 具備較大的執行階段彈性 (因為在連線的情況下,HTML 可以從外部資源或甚至資料庫載入),也可以讓使用者進行自訂。不過,您必須仔細考慮如何避免 HTML 導入惡意的指令碼;而載入及顯示 HTML,以及將控制項的事件連結到應用程式的功能,都必須藉由額外的程式碼才能完成。

  • 應用程式插件

    在您的使用情況中,應用程式的使用者介面可能較適合以其他應用程式的插件來實作,這些應用程式例如 Microsoft Office、AutoCAD、「客戶關係管理」(CRM,Customer Relationship Management) 解決方案、工程工具等等。在這種情況下,您可以利用主應用程式所有的資料擷取和顯示邏輯,而只提供收集資料與使用商業邏輯的程式碼。

    大多數的新式應用程式都將插件視為支援指定介面的「元件物件模型」(COM,Component Object Model) 或 .NET 物件,或是可以反過來叫用自訂物件的內嵌程式開發環境 (例如 Microsoft Visual Basic?程式開發系統,大部分常見的 Windows 應用程式都支援這種開發系統)。某些內嵌環境 (包含 Visual Basic) 甚至還提供表單引擎,讓您可以使用主應用程式以外的使用者介面。 如需在主應用程式中使用 Visual Basic 的詳細資訊,請參閱 MSDN 上的<Microsoft Visual Basic for Applications and Windows DNA 2000>。

    如需從 Microsoft Office 使用 .NET 的詳細資訊,請參閱 MSDN 上的<Microsoft Office and .NET Interoperability>( http://msdn.microsoft.com/en-us/library/aa201326.aspx)。

建立 Windows Form 應用程式時,請考慮下列建議:

  • 使用資料繫結,在同時開啟的多個表單中保持資料的同步性,這樣可以減輕撰寫複雜的資料同步化程式碼的需求。
  • 試著避免在表單之間使用硬式編碼的關係,而使用使用者處理序元件開啟表單,並同步化資料和事件。您應該特別小心,不要從子表單對父表單建立硬式編碼的關係。例如,產品詳細資料視窗可以在應用程式的其他位置重複使用,而不只在訂單輸入表單中使用,所以應該避免在產品詳細資料表單中實作直接連結到訂單輸入表單的功能。如此可提升重複使用使用者介面項目的能力。
  • 在表單中實作錯誤處理常式。這麼做可以避免使用者看到令人不快的 .NET 例外視窗,而且如果沒有對例外進行別的處理,應用程式也不致於失敗。所有的事件處理常式和控制函數都應該包含例外捕捉常式。此外,您也可以為包含中繼資料的使用者介面建立自訂的例外類別,以指示要重試或取消失敗的操作。
  • 驗證使用者介面中的使用者輸入。應該在允許時間點驗證的使用者工作或處理序中進行驗證 (以允許使用者輸入某些必要的資料、繼續進行特定工作或返回目前工作)。在某些情況下,您應該主動啟用和停用控制項,並在輸入資料無效時以視覺方式提示使用者。驗證使用者介面中的使用者輸入,可以避免在輸入資料無效時對伺服器端的元件進行多餘的來回存取。
  • 如果要建立自訂的使用者控制項,請只顯露實際需要的公用屬性及方法。這樣可使元件更易於維護。
  • 將控制函數當作個別的函數實作於 Windows Form 或 .NET 類別中,再將這些 Windows Form 或 .NET 類別部署於用戶端。請不要直接在控制項事件處理常式中實作控制器功能。在事件處理常式中撰寫控制器邏輯會降低應用程式的可維護性,因為以後您可能需要從其他事件叫用相同的函數。

    例如,名為 addItem 的命令按鈕在按一下時的事件處理常式,會呼叫較為一般的程序完成其工作,如以下程式碼所示。

    private void addItem_Click(object sender, System.EventArgs e){  AddItemToBasket(selectedProduct, selectedQuantity)}public void AddItemToBasket(int ProductID, int Quantity){  // code to add the item to the basket}  

Internet 瀏覽器使用者介面

本手冊中說明的零售應用程式需要 Web 使用者介面,讓客戶可以透過網際網路下訂單。Web 使用者介面提供跨多種裝置和平台的標準使用者介面。您可以使用 ASP.NET 為 .NET 應用程式開發 Web 使用者介面。ASP.NET 提供豐富的環境,可以建立支援下列重要功能的複雜 Web 介面:

  • 一致的程式開發環境,也可用來建立應用程式的其他元件。
  • 使用者介面資料繫結。
  • 具有控制項的元件使用者介面。
  • 存取整合的 .NET 安全性模型。
  • 豐富的快取和狀態管理選項。
  • Web 處理的可用性、效能和擴展性。

當您需要實作瀏覽器的應用程式時,ASP.NET 提供發佈 Web 網頁使用者介面所需的功能。請考慮以下 ASP.NET 使用者介面的設計建議:

  • 在 Global.asax 中實作自訂的錯誤網頁和全域的例外處理常式。這可以為您提供捕捉所有例外的函數,以避免發生問題時使用者看到不佳的網頁。
  • ASP.NET 具有豐富的驗證架構,可以確定由使用者輸入的資料符合特定的條件。但是,在瀏覽器所執行的用戶端驗證,必須仰賴用戶端啟用 JavaScript 才能進行,所以最好也要使用控制函數驗證資料,因應使用者的瀏覽器不支援 JavaScript (或 JavaScript 停用) 的情況。如果您的使用者處理序具有 Validate 控制函數,請在轉換到其他網頁前呼叫該函數,以執行時間點驗證。
  • 如果要建立 Web 使用者控制項,請只顯露實際需要的公用屬性及方法。這樣可提升程式的可維護性。
  • 使用 ASP.NET 檢視狀態儲存網頁特定的狀態,並以較廣的資料範圍保存工作階段和應用程式狀態。這種方法使擴展性更易於維護和改良。
  • 您的控制函數應該叫用使用者處理序元件的動作,以指引使用者完成目前的工作,而不是直接將使用者重新導向到網頁。使用者處理序元件可能會呼叫 Redirect 函數,讓伺服器顯示不同的網頁。如果要執行這項作業,必須參考使用者處理序元件的 System.Web 命名空間 (請注意,這表示無法從 Windows 應用程式中重複使用您的使用者處理序元件,所以可能要在不同的類別中實作 Redirect 呼叫)。
  • 在 ASP.NET 網頁或在使用網頁部署的 .NET 中,將控制函數實作為個別的函數。在 ASP.NET 提供的事件處理常式中撰寫商業邏輯會降低網站的可維護性,因為以後可能需要從其他事件叫用相同的函數。這麼做還需要撰寫僅限 UI 程式碼的程式開發人員具備較多的技能。

    例如,假設某個零售網站上的網頁命令按鈕,可以將產品放入使用者的購物車內,該控制項的 ASP.NET 標記可能看來如下:

    <asp:Button id="addItem" OnClick="addItem_Click"/>  

    從上述的程式碼中,您可以看到該按鈕的 OnClick 事件,是由名為 addItem_Click 的函數所處理。不過,該事件處理常式不能包含執行所需動作 (在此情況中是將項目放入購物車) 的程式碼,而應該呼叫其他的一般函數,如下列程式碼所示。

    private void addItem_Click(object sender, System.EventArgs e){  AddItemToBasket(selectedProduct, selectedQuantity)}public void AddItemToBasket(int ProductID, int Quantity){  // code to add the item to the basket}  

    這層額外的架構,可確保執行控制工作所需的程式碼能由多個使用者介面項目重複使用。

如需 ASP.NET 的一般資訊,請參閱 MSDN ( http://msdn.microsoft.com/library/default.asp?url=/nhp/default.asp?contentid=28000440) 和 ASP.NET 官方網站 ( http://asp.net) 的 ASP.NET 部分。

在許多應用程式中,提供可擴充的架構,以顯示具有不同用途的多個視窗是很重要的。在 Web 應用程式中,您還需要提供首頁或根使用者介面,以內容和裝置感應的方式,顯示與使用者相關的工作和資訊。Microsoft 提供下列資源,可以協助您實作 Web 入口:

行動裝置使用者介面

掌上型電腦、「無線應用程式通訊協定」(WAP,Wireless Application Protocol) 電話和 iMode 裝置已越來越普遍,而建立行動表單係數的使用者介面也有本身獨特的挑戰。

一般而言,行動裝置的使用者介面需要能在比一般應用小許多的螢幕上顯示資訊,也必須為開發目標裝置提供可以接受的使用性。因為許多行動裝置的使用者互動可能很不方便 (特別是行動電話),所以在設計行動使用者介面時,資料輸入的需求應該越低越好。常見的策略是將行動裝置的使用與完整大小的 Web 或 Windows 應用程式結合,允許使用者先透過桌面用戶端登錄資料,然後再使用行動用戶端進行選取。例如,電子商業應用程式可以讓使用者先透過網站登錄信用卡詳細資料,這樣從行動裝置下訂單時,便可以從清單中選擇預先登錄的信用卡 (讓使用者不需使用行動電話按鍵或個人數位助理 [PDA] 的手寫筆輸入完整的信用卡詳細資料)。

Web 使用者介面

許多行動裝置都支援網際網路瀏覽。有些使用支援 HTML 3.2 子集的微型瀏覽器,有些需要以「無線標記語言」(WML,Wireless Markup Language) 傳送資料,有些則支援其他的標準,例如「壓縮 HTML」(cHTML,Compact HTML)。您可以使用 Microsoft Mobile Internet Toolkit 建立 ASP.NET 的 Web 應用程式,以根據要求頁首中識別的裝置類型,將正確的標記標準傳送到每個用戶端。這麼做可以讓您針對多樣化的行動用戶端,包括 Pocket PC、WAP 電話、iMode 電話等等,建立單一的 Web 應用程式。

如同其他種類的使用者介面,您應該在行動網頁中盡量降低使用者輸入無效資料的機會。Mobile Internet Toolkit 包含用戶端的驗證控制項,例如 CompareValidator、CustomValidator、RegularExpressionValidator 和 RequiredFieldValidator 控制項,這些可以用於多種用戶端裝置。您還可以使用 Textbox 控制項等輸入欄位的屬性,限制被接受的輸入種類 (例如只接受數值輸入等)。不過,不論用戶端裝置是否支援用戶端驗證,您都應該允許這樣的裝置,並在資料張貼至伺服器後,執行其他的檢查。

如需 Mobile Internet Toolkit 的詳細資訊,請參閱 MSDN 上的 Microsoft Mobile Internet Toolkit 網頁 ( http://msdn.microsoft.com/mobility/default.aspx)。

Smart Device 使用者介面

Pocket PC 是一種功能豐富的裝置,以 Windows CE 作業系統為基礎,可在其上開發離線和連線 (通常透過無線) 使用者介面。Pocket PC 平台包含掌上型的 PDA 裝置和智慧型電話,後者結合了 PDA 和電話功能。

Microsoft 為 Pocket PC 和其他 Windows CE 平台提供 .NET Compact Framework。該簡明架構包含了完整 .NET Framework 的子集,可用來為行動裝置開發豐富的 .NET 應用程式。開發人員可以使用 Smart Device Extensions for Visual Studio .NET 建立針對 .NET Compact Framework 使用的應用程式。

與一般的 Windows 使用者介面相同,您可以在行動裝置中提供例外處理的功能,以在操作失敗時通知使用者,並根據情況讓使用者重試或取消操作。

Smart Device Extensions for Microsoft Visual Studio® .NET 中沒有提供輸入驗證控制項,所以您必須自行實作用戶端驗證邏輯,確保所有的資料輸入有效。

如需 Pocket PC 平台程式開發和 .NET Compact Framework 的更多資源,請參閱 MSDN 上的 Smart Device Extension 網頁 ( http://msdn.microsoft.com/vstudio/device/smartdev.aspx)。

另一項您可以考慮的 Rich Client 行動表單係數是 Tablet PC。Tablet PC 是 Windows XP 的可攜式裝置,以「數位筆和數位墨水」功能支援使用者互動,讓使用者在螢幕上「畫」和「寫」。因為 Tablet PC 是以 Windows XP 為基礎所開發的,因此可以完整地運用 .NET Framework。也有其他的 API 可以處理「數位筆和數位墨水」的互動。如需設計 Tablet PC 應用程式的詳細資訊,請參閱 MSDN 上關於 Pocket PC 運用的<Design Recommendations>( http://msdn.microsoft.com/library/en-us/tpcsdk10/html/whitepapers/designguide/tbconuxdgformfactorpenandink.asp)。

文件使用者介面

在某些狀況下,允許使用者透過以常見工具 (例如 Microsoft Word 或 Microsoft Excel) 建立的文件與系統互動,可能比建立自訂 Windows 桌面應用程式協助使用者互動更有意義。文件可以說是資料使用的基本形式。在某些應用程式中,讓使用者以常用的工具以文件形式輸入或檢視資料,可能很有助益。請考慮下列的文件解決方案:

  • 報告資料:應用程式 (Windows 或 Web) 可以為使用者提供以適當類型的文件檢視資料的功能:例如,以 Word 文件顯示發票資料,或以 Excel 試算表顯示價格清單。
  • 收集資料:可以讓業務代表在 Excel 試算表中輸入電話客戶的購買資訊,建立客戶訂購文件,然後將該文件傳送到商業處理流程。

在應用程式中整合文件有兩種常見的方式,每個方式又可細分為兩種常見案例:向使用者收集資料以及報告資料給使用者。

使用來自外部的文件

您可以使用「來自外部」的文件,並將它們當作一個項目。在這種狀況中,文件所使用的程式碼,並不受到應用程式的影響。這種方式的優點在於文件檔案可以保留至其他的工作階段。當文件中有應用程式不需要處理但可能需要保留的「隨意」(Freeform) 區域時,這種模型很有用。例如,您可以選擇這個模型,讓使用者在行動裝置上的文件中輸入資訊,並利用 Pocket PC ActiveSync 的功能,在行動裝置上的文件和伺服器上保留的文件之間同步化資料。在這種設計模型中,使用者介面會執行下列功能:

  • 收集資料。使用者可以在文件中輸入資訊、從空白文件開始,或者更常見的是從預先定義、具有特定欄位的範本開始作業。

    接著使用者將文件傳送到 Windows 應用程式或將其上載到 Web 應用程式。應用程式透過文件的物件模型掃描文件的資料和欄位,然後執行必要的動作。

    此時,您可以決定要在處理過後保留文件或將其處置 (Dispose)。通常會保留文件,以維護追蹤記錄或儲存使用者在隨意區域中輸入的資料。

  • 報告資料。在這種情況中,會以 Windows 或 Web 使用者介面提供方式,以產生文件顯示某些資料,例如業務發票等。報告程式碼通常會從正在進行的使用者處理序、商業處理流程和/或資料存取邏輯元件取得資料,然後呼叫文件應用程式的巨集注入資料並加以格式化,或用正確的檔案格式儲存文件,然後將其傳回給使用者。您可以將文件儲存到磁碟並提供連結 (需要將文件儲存在負載平衡的 Web 伺服陣列的中央存放區),或者將該文件包含在回應中等方式來傳回。

    如果要在 Web 應用程式中傳回文件,則必須決定是否要將文件顯示在瀏覽器中供使用者檢視,或讓使用者可以選擇將文件儲存到磁碟。這通常是藉由在 ASP.NET 網頁的回應上設定正確的 MIME 類型加以控制的。在 Web 環境中要注意遵守檔案命名慣例,以避免同時使用的使用者覆寫對方的檔案。

使用來自內部的文件

想要在文件內提供整合的使用者經驗時,可以將應用程式邏輯內嵌於文件本身。在此設計模型中,使用者介面會執行下列功能:

  • 收集資料。使用者可以在具有預先定義表單的文件中輸入資料,然後範本上的特定巨集會被叫用,以收集正確的資料並叫用商業或使用者處理序元件。這種方式提供較為整合的使用者經驗,因為使用者只需在主應用程式中按一下自訂的按鈕或功能表選項,即可執行工作,而不需傳送整個文件。
  • 報告資料。您可以在文件中實作自訂的功能表項目和按鈕,從伺服器收集某些資料並加以顯示。也可以在文件中選擇使用智慧標籤,為所有的 Microsoft Office 工具提供豐富的內嵌整合功能。例如,您可以提供智慧標籤,在業務代表於文件中輸入客戶名稱時,顯示取自 CRM 資料庫的完整客戶聯絡資料。

無論是使用來自內部或外部的文件,都應該提供驗證邏輯,以確認所有的使用者輸入都有效。您可以藉由限制欄位的資料類型達到這項目的,但在大部分的情況下,您都需要實作自訂功能來檢查使用者輸入,並在偵測到無效資料時顯示錯誤訊息。Microsoft Office 文件可以包含自訂的巨集來提供這項功能。

如需如何在商業處理流程中整合純粹的 Office UI 的詳細資訊,請參閱<Microsoft Office XP Resource Kit for BizTalk Server Version 2.0>( http://www.microsoft.com/downloads/details.aspx?familyid=c4c7cb91-7095-4935-b615-4cfb739704e7&languageid;=f49e8428-7071-4979-8a67-3cffcb0c2524&displaylang;=en)。

如需使用 Office 和 .NET 的詳細資訊,請參閱 MSDN。以下兩篇文章可協助您開始進行 Office 和 .NET 的應用程式開發:

您可利用 Microsoft SharePoint Portal™ 所提供的服務管理文件的工作流程。這項產品可以管理使用者處理序,並提供完善的中繼資料和搜尋功能。

從使用者介面存取資料存取邏輯元件

有些應用程式的使用者介面需要呈現的資料,是由資料存取邏輯元件顯露的查詢。無論使用者介面元件是否直接叫用資料存取邏輯元件,都不應該混用資料存取邏輯與商業處理邏輯。

直接從使用者介面存取資料存取邏輯元件,似乎與分層的概念相左。不過,在這種情況下,將應用程式當成一個同質的服務是很有用的也就是在呼叫該應用程式後,要用什麼內部元件回應要求,是由該應用程式決定。

在下列情況時,應該允許資料存取邏輯元件直接存取使用者介面元件:

  • 您願意將資料存取方法和結構描述與使用者介面語法緊密結合。這類的緊密結合需要同時維護使用者介面的變更和結構描述的變更。
  • 您的實體部署將資料存取邏輯元件和使用者介面元件放置在一起,使您可以透過資料流的格式 (例如 DataReader) 從資料存取邏輯元件取得資料,這些元件可以直接與 ASP.NET 使用者介面的輸出繫結,以達到更高的效能。如果在不同的伺服器上部署資料存取和商業處理流程邏輯,便無法利用這項功能。從操作的觀點來看,允許直接存取資料存取邏輯元件來利用資料流功能,代表您需要對其中部署了資料存取邏輯元件的資料庫提供存取這可能包括透過防火牆連接埠進行存取。如需詳細資訊,請參閱第 4 章< 實際的部署及操作需求>。

設計使用者處理序元件

與應用程式進行使用者互動可能會遵循可預測的程序﹔例如,零售應用程式可能需要使用者輸入產品詳細資料、檢視總價格、輸入付款詳細資料,最後輸入運送地址資訊。這項程序包含顯示和接受數種使用者介面項目的輸入,而程序的狀態 (哪些產品被訂購、信用卡的詳細資料等等) 則必須在程序中的步驟轉換之間加以保留。為了在顯示多個使用者介面網頁或表單時,協調使用者處理序及處理所需的狀態管理,可以建立使用者處理序元件。

注意事項:實作與使用者處理序元件的使用者互動,不是一件簡單的工作。在採用這個方法前,應該仔細評估應用程式是否需要使用者處理序元件所提供的協調和區隔等級。

使用者處理序元件通常是實作為 .NET 類別,這些類別會顯露可以由使用者介面呼叫的方法。每種方法都會封裝在使用者處理序中執行特定動作所需的邏輯。使用者介面建立使用者處理序元件的例項,並用它在處理序的步驟之間進行轉換。在處理序每個步驟中顯示的特定表單或 ASP.NET 網頁的名稱,可以用硬式編碼的方式寫在使用者處理序元件中 (如此才能將該元件緊密地繫結到特定的使用者介面實作),或者也可以從設定檔案之類的中繼資料存放區擷取這些名稱 (這樣從多個使用者介面實作中重複使用使用者處理序元件會較為容易)。設計從多個使用者介面使用的使用者處理序元件,會造成較為複雜的實作,因為如此才能區隔裝置特定的問題,但這也可以幫助您在多個團隊之間分配使用者介面的程式開發工作,且每個團隊都使用相同的使用者處理序元件。

使用者處理序元件協調使用者介面項目的顯示。這些項目均與使用者介面元件所提供的資料呈現和取得功能有所區隔。您應該在設計這些項目時,考慮全球化的問題,讓使用者介面可以本土化。例如,您應該力圖使用文化中立的資料格式,並在內部使用 Unicode 字串,這樣較易於從本土化的使用者介面利用使用者處理序元件。

下列程式碼顯示結帳程序的使用者處理序元件的可能形式。

public class PurchaseUserProcess {   public PurchaseUserProcess()   {     // create a guid to track this activity     userActivityID = System.Guid.NewGuid();   }   private int customerID;   private DataSet orderData;   private DataSet paymentData;   private Guid userActivityID;   public bool webUI; // flag to indicate that the client UI is a Web   // site (or not)  public void ShowOrder()   {     if(webUI)     {             //Code to display the Order Details page      System.Web.HttpContext.Current.Response.Redirect                          ("http://www.myserver.com/OrderDetails.aspx");    }     else // must be a Windows UI    {       //code to display the Order Details window.       OrderDetails = new OrderDetailsForm();      OrderDetails.Show();     }   }   public void EnterPaymentDetails()   {    // code to display the Payment Details page or window goes here  }   public void PlaceOrder()   {     // code to place the order goes here    ShowConfirmation();  }   public void ShowConfirmation()  {     // code to display the confirmation page or window goes here  }   public void Finish()  {     //code to go back to the main page or window goes here   }   public void SaveToDataBase()   {     //code to save your order and payment info in the private variables     //to a database goes here  }  public void ResumeCheckout(System.Guid ProcessID)  {    // code to reload the process state from the database goes here  }  public void Validate()    {     //you would place code here to make sure the process     //instance variables have the right information for the current step   } }  

將使用者互動功能分隔為使用者介面和使用者處理序元件,具有下列優點:

  • 較易於保存長期執行的使用者互動狀態,這樣可以放棄及繼續使用者互動,就算使用的是不同的使用者介面也是如此。例如,客戶可以使用 Web 使用者介面在購物車中加入項目,然後稍後打電話給業務代表完成訂購。
  • 相同的使用者處理序可以由多個使用者介面重複使用。例如,在零售應用程式中,可以使用相同的使用者處理序,從 Web 使用者介面和 Windows Form 應用程式將產品加入購物車。

使用者介面邏輯的設計方法如果不夠嚴謹,可能會導致不利的狀況,例如應用程式的大小增加或造成新的需求。如果需要為指定裝置新增特定的使用者介面,可能需要重新設計資料流程和控制邏輯。

將使用者互動作業與從使用者收集和呈現資料的活動加以分割,可以增加應用程式的可維護性,並提供簡潔的設計,供您在其中輕鬆地增加表面上很複雜的功能,例如離線工作的支援。圖 2.4 顯示如何區隔使用者介面和使用者處理序。

ms978348.f02apparch04(zh-tw,MSDN.10).gif

圖 2.4 使用者介面和使用者處理序元件

使用者處理序元件可協助您解決下列的使用者介面設計問題:

  • 處理同時使用者活動。有些應用程式可以提供一種以上的使用者介面項目,讓使用者同時執行多項工作。例如,Windows 應用程式可以顯示多個表單或 Web 應用程式可以開啟第二個瀏覽器視窗。

    使用者處理序元件可以在單一元件中封裝處理序所需的全部狀態,以簡化多個持續進行的處理序的狀態管理。您可以在設計中包含自訂的處理序識別項,以將每個使用者介面項目對應到使用者處理序的特定例項。

  • 使用多個窗格進行一個活動。如果特定的使用者活動中使用了多個視窗或窗格,則對它們進行同步化是很重要的。在 Web 應用程式中,使用者介面通常會在同一網頁中,為指定的使用者活動顯示一組項目 (可能包含框架)。但是,在 Rich Client 應用程式中,單一特定的處理序實際上可能是由多個非強制回應的視窗來操作。例如,您可以在應用程式中放置一個浮動的產品類別選擇器視窗,用來指定特定的類別,而其中的產品則會顯示在其他視窗中。

    使用者處理序元件可以將所有視窗的狀態集中在單一位置,以實作此類型的使用者介面。您可以使用可繫結資料的格式來儲存狀態資料,以進一步簡化多個使用者介面項目的同步化作業。

  • 隔離長期執行的使用者活動與商業相關狀態。某些使用者程序可以暫停,然後稍後再繼續。使用者處理序的中繼狀態通常應該與應用程式的商業資料分開儲存。例如,使用者可以指定下訂單所需的一些資訊,然後稍後再繼續結帳程序。擱置的訂單資料應該與已完成訂單的資料分開保存,這樣就可以對已完成的訂單資料執行商業操作 (例如,計算本月份所下的訂單數量),不需實作複雜的篩選規則以避免處理未完成的訂單。

    就像商業處理流程一樣,使用者活動可能會指定「逾時」,以指出何時必須取消活動、對商業處理流程採取正確的補償動作。

    您可以將使用者處理序元件設計為可序列化,或將它們的狀態與應用程式的商業資料分開儲存。

分隔使用者處理序和使用者介面

如果要分隔使用者處理序和使用者介面:

  1. 識別透過使用者介面處理序完成的商業處理流程。識別使用者處理這項工作的方式 (這通常可藉由參考您在需求分析時所建立的順序圖表進行)。
  2. 識別商業處理流程所需的資料。在必要時,使用者處理序必須能夠傳送這項資料。
  3. 識別在使用者活動時需要維護的其他狀態,以在使用者介面中進行資料呈現和擷取。
  4. 設計使用者處理序的視覺流程,以及每個使用者介面項目接收或提供控制流程的方式。

您還需要實作程式碼,將特定的使用者介面工作階段對應到相關的使用者處理序:

  • ASP.NET 網頁必須取得目前的使用者處理序,方法是從 Session 物件取得參考,或者從其他的儲存媒體 (例如資料庫) 重生該處理序。網頁控制項的事件處理常式需要使用這個參考。
  • 視窗或控制項需要保留對目前使用者處理序元件的參考。您可以用成員變數來保存這個參考,但不能用全域變數加以保存。如果這麼做,隨著應用程式使用者介面的擴充,撰寫使用者介面的工作會變得十分複雜。

使用者處理序元件功能

使用者處理序元件:

  • 提供簡單的方式,在不需重新開發資料流程和控制邏輯的情況下,將使用者介面項目與使用者互動作業結合。
  • 將概念性的使用者互動作業,與發生該作業的實作或裝置加以區隔。
  • 封裝例外影響使用者處理序流程的方式。
  • 追蹤使用者互動的目前狀態。
  • 不能啟動或參與交易。交易會保留與應用程式商業邏輯和其內部狀態相關的內部資料,並依需要保存資料。
  • 維護內部商業的相關狀態,通常會保存受使用者互動所影響的一或多個商業項目。您可以用私用變數、內部陣列或適當的集合型別,保存多個項目。如果是 ASP.NET 應用程式,您還可以選擇以 Session 物件保存此資料的參考,但這麼做會限制使用者處理序的有效存留期 (Lifetime)。
  • 可以提供「儲存並稍後繼續」功能,可以在其他的工作階段重新啟動特定的使用者互動作業。您可以用永續性 (Persistent) 的表單儲存使用者處理序元件的內部狀態,並讓使用者稍後繼續特定活動的方式實作這項功能。您可以建立自訂的工作管理員公用程式元件,以控制處理序目前的啟動狀態。使用者處理序狀態可以儲存在以下任何一個位置:
    • 如果使用者處理序可以從其他裝置或電腦繼續,則必須將它集中儲存在資料庫之類的位置。
    • 如果是在中斷連線的環境中執行,則使用者處理序狀態必須儲存在本機使用者裝置。
    • 如果使用者介面處理序是以 Web 伺服陣列執行,則必須將必要的狀態儲存在中央的伺服器位置,如此該處理序才能從伺服陣列內的任何伺服器繼續作業。
  • 可以藉由呼叫商業處理流程元件或資料存取邏輯元件,初始化內部狀態。
  • 通常不會實作為 Enterprise Services 元件。這樣做的唯一理由是為了使用 Enterprise Services 角色授權功能。
  • 可以由管理應用程式功能表的自訂公用程式元件啟動。

使用者處理序元件介面設計

使用者處理序元件的介面,可以顯露以下類型的功能,如圖 2.5 所示。

ms978348.f02apparch05(zh-tw,MSDN.10).gif

圖 2.5 使用者處理序元件設計

  • 使用者處理序「動作」(1):指動作的介面,這些動作通常會觸動使用者處理序的狀態變更。動作是由使用者處理序元件方法所實作,如稍前所討論的程式碼範例中展示的 ShowOrder、EnterPaymentDetails、PlaceOrder 和 Finish 方法。您應該試著以這些動作方法 (6) 封裝對商業元件的呼叫。
  • 狀態存取方法 (2):您可以使用僅顯露一個值的精密 get 及 set 屬性,或者藉由顯露使用者處理序處理的商業項目集 (5),存取使用者處理序的商業特定狀態和適用於多種商業的狀態。例如,在稍前所討論的程式碼範例中,使用者處理序狀態可以透過公用的 DataSet 屬性來擷取。
  • 狀態變更事件 (3):每當使用者處理序的商業相關狀態或適用於多種商業的狀態變更時,這些事件便會發生。有時候您需要自行實作這些變更通知。在其他情況下,則可能透過已在內部執行這項作業的機制儲存資料 (例如,當資料變更時,資料集就會啟動事件)。
  • 讓您啟動、暫停、重新啟動及取消特定使用者處理序的控制函數 (4):這些函數應該分開保存,但也可以與使用者處理序動作混用。例如,稍前所討論的程式碼範例包含了 SaveToDataBase 和 ResumeCheckout 方法。控制方法可以從資料存取邏輯元件 (7) 載入 UI 的必要參考資料 (例如填滿下拉式方塊所需的資訊),或者將這項工作委派給需要資料的使用者介面元件 (表單、控制項、ASP.NET 網頁)。

使用者處理序元件的一般建議

設計使用者處理序元件時,請考慮下列建議:

  • 決定您是否需要將使用者處理序當作與使用者介面實作分隔的元件加以管理。具有許多使用者介面對話方塊或使用者處理序可能需要自訂而適合插件的應用程式,最需要分隔的使用者處理序。
  • 選擇使用者處理序狀態要儲存於何處:
    • 如果處理序是以連線方式執行,則將長期執行處理序的過渡狀態儲存於中央 SQL Server 資料庫;如果是中斷連線的情況,則請將狀態資訊儲存於本機的 XML 檔案、隔離的存放區或本機的 Microsoft SQL Server™ 2000 Desktop Engine (MSDE) 資料庫。在 Pocket PC 裝置上,則可以將狀態儲存於 SQL Server CE 資料庫。
    • 如果處理序不是長期執行,且不需在發生問題時復原,則應該將狀態保存在記憶體中。如果是針對 Rich Client 所建立的使用者介面,也可以將狀態保存在記憶體中。如果是 Web 應用程式,則可以選擇將使用者處理序狀態儲存在 ASP.NET 的 Session 物件中。如果是在 Web 伺服陣列中執行,則應該在中央狀態伺服器或 SQL Server 資料庫中儲存工作階段。ASP.NET 會清除 SQL Server 儲存的工作階段,避免過時資料堆積。
  • 將使用者處理序元件設計成可以序列化。這可以協助您實作任何保存性配置。
  • 在使用者處理序元件中包含例外處理功能,並將例外傳播到使用者介面。由使用者處理序元件所擲回的例外,會由使用者介面元件捕捉並加以發佈,如第 3章< 安全性、操作管理與通訊原則>中所述。

網路連線和離線應用程式

在許多情況下,您的應用程式都需要在網路連線無法使用時,支援離線操作。例如,許多行動應用程式,包括 Pocket PC 的 Rich Client 或平板電腦裝置,都必須能在使用者與企業網路中斷連線時作用。離線應用程式必須依賴本機資料和使用者處理序狀態執行其作業。設計離線應用程式時,請遵循以下內容中的一般指導方針。

必須為使用者顯示連線和離線狀態,通常會在狀態列或標題列顯示,或在需要連線到伺服器的使用者介面項目周圍顯示視覺提示。

大部分應用程式使用者介面的程式開發都要可以重複使用,且不需任何修改 (或只需稍微修改) 即可支援離線狀況。離線時,應用程式不能:

  • 存取由資料存取邏輯元件所傳回的線上資料。
  • 同步叫用商業處理流程。因此,應用程式將無法判斷呼叫是否成功,或是否可以使用任何傳回的資料。

如果應用程式沒有對伺服器實作完整的訊息介面,而是依賴同步取得資料以了解商業處理流程的結果 (目前大部分的應用程式都是如此),則應該進行下列作業以提供連線的錯覺 (Illusion):

  • 為使用者活動相關的唯讀參考資料,實作本機快取。接下來可以實作離線的資料存取邏輯元件,該元件會實作與伺服器端的資料存取邏輯元件完全相同的查詢,但存取本機存放區。您可以將本機快取實作為桌面 MSDE 資料庫。這可讓您重複使用主要 SQL Server 結構描述和預存程序的設計和實作。不過,MSDE 會影響它所在電腦的全域狀態,如果從配置為非完全信任的應用程式對其進行存取,可能會遇到困難。對您的狀態保存性需求而言,在許多狀況下,使用 MSDE 可能會矯枉過正,而將資料儲存在 XML 檔案或永久的資料集內,可能是較佳的方案。
  • 實作與您的商業元件具有相同介面的離線商業元件,但將傳送的資料放置於具有存放及轉寄功能的可靠訊息系統中,例如「訊息佇列」。接下來這個離線元件可以將空值或預設值傳回給呼叫者。
  • 實作 UI 功能,提供方法檢查商業動作「寄件匣」並刪除其中訊息。如果使用「訊息佇列」將離線訊息排入佇列,則需要在佇列上設定正確的使用權限,才能從應用程式執行這項作業。
  • 將應用程式的交易設計成可容納訊息 UI 互動。在管理開放式鎖定以及根據過時資料所得的交易結果時,必須更小心謹慎。一項執行更新的常見技術是同時傳送新舊資料,並讓相關的商業處理流程或資料存取邏輯元件自然解決任何衝突。對於商業處理流程而言,傳送的資料可能包含關鍵性的參考資料,商業邏輯會使用這些參考資料決定是否要讓資料通過。例如,在傳送訂單時,除了產品識別碼和數量外,還可以包含產品價格。如需開放式鎖定的詳細資訊,請參閱 MSDN 上的<Designing Data Tier Components and Passing Data Through Tiers>(
相簿設定
標籤設定
相簿狀態