提前設計應用程式，使其滿足使用者對不只一個介面的需求。
by Robert Ericsson and Jason Cline
涉及技術：.NET Framework, ASP.NET, Windows Froms, .NET Compact Framework, Mobile Internet Toolkit
下載本文代碼(http://www.fawcette.com/China/DotNetMagazine/2002_12/code/nm0212re.zip)
對於你們開發小組開發的軟體，你可能想給使用者提供最佳的使用者介面，這就意味著你需要不只一個介面。使用者希望可以在任何時候、任何地點、在各種裝置上訪問資訊。這就形成了人們對靈活介面的需求，而且使應用程式的基本原理和使用者介面的設計和建立顯得更為重要了。在本篇文章中，我們將講述一些用來定義、設計、構建和測試支援.NET多個使用者介面的應用程式的最好的方法。我們的探討只局限於現有的以及很快會實現的用於.NET平台的開發技術。然而，如果你們的Team Dev已經建立了一個Java前端系統，並通過.NET Web services來運行一個伺服器端應用程式的話，這些方法也同樣適用。
在Rob Ericsson的“為好的UI 選擇合適的工具”(http://www.fawcette.com/China/XmlFile.aspx?ID=25)一文中，他講述了應用程式的一些特點，可以幫你選擇是用Windows Forms還是用ASP.NET來實現一個應用程式。這種選擇的要點就是要對每種技術進行成本效益分析，將應用程式的可用性作為一個最重要的因素來考慮。然而，這通常並不是一個簡單的二選一的問題。有時侯，一個應用程式有很多不同的使用者群。所以，使用者的需求以及他們對使用者介面的需求會有很大的差別就不足為奇了。對於這種類型的應用程式，“一刀切”（one-size-fits-all）式的Windows Forms或ASP.NET實現方式可能就不太適合了。
在這種情況下，你應該考慮建立一個可以提供多個使用者介面的應用程式。對於這種具有多個介面的應用程式，我們可以將Microsoft Exchange Server作為例子來講述：Outlook是Windows用戶端，Outlook Web Access （OWA）是基於Web的介面。你臨時不在辦公室時使用OWA是很理想的，而Outlook Windows用戶端是設計用於大量的日常工作的。然而，不同的介面並沒有必要用不同的技術來構建。讓我們來看一個客戶服務中心的應用程式。客戶服務電話接線員運用的資料錄入介面同用來管理應用程式的介面有很大的不同，雖然它們都是用Windows Forms構建的。實際上，運用相同的介面技術來建立兩個不同的介面比將多個介面技術整合到一個應用程式中要簡單得多。
認可困難
雖然一些工具供應商認為建立具有多個使用者介面的應用程式很簡單，但事實並非如此。很多時候，建立一個Web或PDA應用程式所帶來的興奮感都會讓開發人員失去理智，從而不去考慮Windows應用程式是否對使用者更有效。另外添加一個介面會給你的應用程式帶來許多複雜的問題，所以不要輕易作出這樣的決定。為了協助你決定是否給你的應用程式採用多個使用者介面，你應該問自己這樣幾個問題。
第一，使用者不在辦公室時需要訪問你的應用程式嗎？對遠端使用者的支援是提供多個介面的主要原因。在許多情況下，這些使用者確實需要一個單獨的介面來運用應用程式。使用者在一個擁擠的飛機場和在一個安靜的辦公室所使用的環境是完全不同的。
第二，你的應用程式需要在不同的平台上運行嗎？因為.NET目前不提供跨平台的互用性，所以如果你的需求包括在非Windows作業系統上運行應用程式，那麼你就應該建立一個ASP.NET應用程式，使使用者可以從多個Web瀏覽器訪問它（見工具條“.NET正走向成功”）。如果你運用Microsoft Mobile Internet Toolkit，所支援的Web瀏覽器可以包括那些在Palm OS PDAs和手機上啟動並執行瀏覽器。
最後，你有需求截然不同的使用者群嗎？在著手開發應用程式前，仔細考慮這些問題是很值得的，否則會造成相當大的麻煩並給應用程式帶來風險。只有當你確信你的應用程式使用者的確需要多個介面時，你才可以投資來構建它們。
選擇你的技術
一旦你決定構建一個具有多個介面的應用程式，你就需要確定運用哪種技術。.NET提供了許多使用者介面選項，要對建立一個具有多個介面的.NET應用程式作出合理的選擇，你就必須充分瞭解.NET相關的介面技術。
Windows Forms是在.NET中開發富用戶端（rich client）應用程式的基礎。用戶端應用程式比其相應的基於瀏覽器的應用程式有一些固有的優勢。使用者可以運用用戶端應用程式，而不需要網路連接。雖然在辦公環境中網路已經無處不在了（尤其是隨著諸如802.11這樣的無線網路技術的普及），但在不能利用網路連接的情況下，使用者仍需要很多應用程式。例如，他們可能需要在家運用一個應用程式，在這種情況下，只有很少數的使用者有寬頻連線；或者需要在車間運用應用程式，這時候由於電磁幹擾而不能進行網路連接；或者在乘飛機旅行時。除了提供離線功能外，用戶端應用程式也可以充分利用Windows的特殊功能，而基於瀏覽器的應用程式只能運用Windows“最低標準”的功能。
Windows Forms是Microsoft Foundation Classes（MFC）的“指定繼承人”，它是Win32 API使用者介面庫的首選對象封裝器（object wrapper），但是MFC和Windows Forms之間有許多不同。嚴格地說，MFC是個C++類的模式，而任何.NET語言都可以訪問Windows Forms的類。另外，類的模式的靈活性和可用性都有了很多改進。由於MFC本質上是Win32上的一個thin wrapper，所以它有很多不一致性，而且很難學習並有效運用。Windows Forms類的模式是經過了改進的，一致的，它的學習曲線類似於Visual Basic的學習曲線，而且有更多的功能。運用Windows Forms，我們可以完成任何通過直接寫到Win32類庫來完成的任務。如果你需要擴充類來支援你的應用程式的一個特殊的使用者介面，你可以通過繼承Windows Forms的類來實現。
運用MFC或Visual Basic建立用戶端應用程式的一個最大的缺點就是發布應用程式和所有必需的DLLs很困難。用戶端應用程式的安裝步驟通常很複雜，而且可能很麻煩。Windows Forms的智能用戶端使我們可以在開發應用程式時將富用戶端的強大性和靈活性與基於瀏覽器的應用程式容易發布的特點結合起來。
ASP.NET是在.NET中建立基於Web的應用程式的重要技術。近幾年來，基於Web的應用程式已經超越了簡單的資料庫存取前端系統的範圍，它包括許多不同的應用。基於Web的應用程式對用戶端的限制非常低，這就是它們很受歡迎的一個原因。任何可以通過網路訪問Web伺服器的機器都可以運用一個將符合標準的HTML發送到瀏覽器的應用程式。在介面功能上你需要考慮這種功能，使使用者可以在任何Web瀏覽器上訪問一個應用程式，但是對於許多應用程式來說，固有的HTML標籤提供的基本的使用者介面組件就足夠建立一個可用的介面了。
除了可以建立基於HTML的應用程式外，ASP.NET也使建立基於SOAP（Simple Object Access Protocol）的Web services變得非常容易了。在一個用戶端應用程式中使用一個Web services也很簡單。因為通過運用.NET的SOAP可以很容易地建立用戶端/伺服器應用程式，所以在你的應用程式中提供多個介面就變得更容易了。將Web services同富用戶端結合起來就可以讓使用者享有Web應用程式和富用戶端的好處，從而彌補了它們各自的不足。
你在考慮PDA使用者介面時會有新的想法。雖然對PDAs的大肆宣傳已經減少了，但它們仍代表了使用者訪問社團資訊的一種方式。Gartner Dataquest預言在2002年會生產1550萬PDAs。由於PDA的螢幕更小、輸入技術有限以及典型的使用環境，所以對PDA介面的需求同對一個Windows或Web應用程式的需求有很大的不同。
因為為PDA設計可用的應用程式與Windows或Web應用程式的開發截然不同，所以.NET提供了工具以簡化該步驟。Visual Studio .NET的Smart Device Extensions可以讓開發人員運用.NET 工具（他們已經很熟悉了）來建立.NET Compact Framework應用程式。.NET Compact Framework是.NET Framework的一個子集，它在資源受到限制的（resource-constrained）裝置上運行，如Pocket PC PDAs、智能電話和其它運行Windows CE .NET的裝置。
.NET Compact Framework提供了必要的工具來建立可用的應用程式，包括用戶端對Web services的訪問、ADO.NET、加密、適當的繪圖和表單功能。除了只在Pocket PC裝置上啟動並執行.NET Compact Framework外，.NET也具有Microsoft Mobile Internet Toolkit（MIT）的特點。這個ASP.NET的擴充功能可以讓開發人員在各種裝置上建立Web應用程式，包括支援WAP的手機和大多數運行Palm OS的PDAs。它包含一組伺服器端的控制項，為列表、命令、通話、日曆等提供使用者介面元素。控制項根據訪問裝置自動提供適當的標識語言（HTML、WML、cHTML）。這就可以讓你把精力集中到應用程式邏輯的開發和使用者回饋上，而MIT則負責無線開發的細節。
付諸實施
.NET提供了許多使用者介面技術。為了有助於你瞭解如何運用它們，我們建立了一個範例應用程式，它有兩個介面：一個Windows Forms用戶端和一個ASP.NET用戶端。範例是個時間跟蹤和專案管理應用程式，是為一個專門的服務公司開發的，用來跟蹤客戶項目所花的時間。該應用程式有明顯的需求不同的使用者群，可以很好地說明多使用者介面的應用。
在定義時間跟蹤應用程式的根本的需求時，我們確定了四種不同的使用者群：專案經理、顧問經理、顧問和訂約人。前兩種使用者需要資料輸入和報表分析的功能，而後兩種使用者只需要資料輸入和遠端存取功能。因為這些使用者群的需求不同，所以我們把應用程式分成兩個介面：一個用於管理和分析的Windows Forms應用程式，和一個用於資料輸入和遠端存取的ASP.NET Web Forms應用程式。
花時間瞭解應用程式的不同使用者群的需求是很有價值的，而這個步驟經常被人們忽視（見工具條“建立可用性需求”）。在著手設計應用程式時瞭解使用者群的需求可以使你的程式的重用性達到最大，還可以避免產品開發中的重複勞動。因為我們在設計應用程式時有了這樣的瞭解，所以我們就可以用ASP.NET Web services了，並可以構建一個支援多個使用者介面平台的簡單而有效應用程式。
集中的、跨平台的商業邏輯的一個危險就是在所有使用者介面平台上實現該商業邏輯提供的全部功能。重要的一點是，我們應該關注個別介面的需求，不要因為可以得到某種商業邏輯提供的功能就去實現它。恰當的做法是要瞭解你的使用者群並始終考慮他們的需求。
根據我們建立.NET應用程式的經驗，我們已經掌握了一些有用的東西，在此我們將分享給你。軟體開發中最大的挑戰之一就是收集並記錄需求。你努力去解決的問題（需求）往往會和那個問題的建議性解決方案（設計）混淆在一起。基本的用例可以幫你分辨需求和設計（見資源）。將基本用例與具體用例進行比較，你會發現具體用例中說明了使用者和一個特殊介面之間的實際互動。當你編寫一個具體用例時，你已經建立了（至少是含蓄地）使用者介面。這種不成熟的介面設計可能在以後的開發週期中造成許多問題，尤其是如果你在你的應用程式中用了多個介面的話。如果用例指定了一個具體的依賴於特殊的Windows控制項的互動層，那麼當互動媒介發生改變時，你就必須修改需求。這就會導致需求的脆弱性，它會阻止正常的設計進程並延遲開發。
仔細設計商業邏輯
在確定需求時，除了要非常注意細節外，我們發現仔細設計商業邏輯層尤為重要。最重要的是，如果你打算運用Web services，你就需要注意管理序列化和傳送域對象的媒介的局限性。設計和構建適當的Web services是該問題的關鍵：這個問題解決得好就可以讓你在.NET中更容易地運用多個介面。雖然Web services伴隨有許多誇張的宣傳，但在多個介面設計方面，它們的靈活性確實是不可比擬的。
你也需要瞭解你的應用程式將呈現的介面的相關的技術細節。例如，用戶端技術如何處理狀態？雖然ASP.NET為Web應用程式簡化了狀態處理，但如果你的應用程式將有一個Web介面時，這仍然是個需要考慮的問題。因為Web依賴於無狀態的HTTP協議進行通訊，因此確定如何跟蹤一個使用者在應用程式的位置這一負擔就落在了應用程式開發人員的身上。在ASP.NET中跟蹤狀態比用以前的技術跟蹤狀態要容易很多，但你仍需要確定在你的應用程式中如何跟蹤並運用狀態資訊。在設計應用程式時考慮其它問題（包括資料結構和持久性）也是很重要的。HTTP本身不支援傳送和保持資料結構（同保持狀態的問題類似），所以你必須確定如何在你的應用程式中實現它們。幸運的是，ASP.NET的便於使用的SOAP實現方式可以幫你解決這個問題。
忽視可用性是你在多介面應用程式中可能犯的最大的一個錯誤。對功能加以限定是種很好的方法：越少越好。在一個介面載入過多的功能會變得很混亂，而且很難使用。如果你遵循Bauhaus的設計格言——形式追隨功能，那麼就會得到更好的結果。瞭解你的應用程式可以提供的功能以及使用者如何使用那些功能對於建立一個可用的應用程式來說是很必要的。這可能意味著，每個平台的介面根據那類使用者期望的功能的不同而有很大的不同。
在範例應用程式中，Web和Windows Forms介面明顯不同，因為我們有不同的使用者群，他們的使用模式不同。運用該應用程式的顧問對建立漂亮的報表不感興趣；他們只想根據項目記錄時間。給他們提供“額外”的報表分析功能可能是個好主意，但是最小限度地增加複雜性都會造成應用程式總成本的增加。如果顧問們需要額外的報表功能，那麼我們應該一步步地收集需求並構建該功能。
先測試最重要的UI
有時侯你可能不需要多個介面，你可以通過先測試最重要的介面來確定這一點。例如，如果應用程式的主要使用者是內部Windows案頭使用者，你可能認為智能用戶端介面是最重要的。另一方面，如果主要使用者是一群移動使用者，你可能選.NET Compact Framework介面。不管你選擇哪個介面，你應該首先建立這個最重要的介面，對它進行測試來看看你是否真的需要提供另外的介面。這就可以讓你有機會仔細關注應用程式商業邏輯，並確信它是否非常穩固。通過一些可用性測試，你可能發現Web介面“需求”是不需要的，如果你有一個設計良好的Windows Forms智能用戶端應用程式的話。如果測試表明你需要多個介面，你可以從最先發布的介面收集使用者反饋，它們可以用來改進未來介面的設計。
.NET Framework提供了很多技術可以使建立多個使用者介面的工作變得簡單。然而，在建立有效使用者介面方面並沒有什麼“尚方寶劍”。不管你用什麼工具，仍然會有可用性這個基本問題：需要對使用者群及其使用者有所瞭解。一旦你瞭解了這些，你的開發小組就需要設計一個使用者介面使使用者可以更有效地執行他們的任務了。最後，開發小組需要測試這個使用者介面，確信它確實是個有效解決方案。
多個使用者群對一個應用程式的介面需求會截然不同，這種情況會越來越多，你可以利用.NET工具來建立你需要的介面。Windows Forms為Windows使用者提供強大的、智能用戶端功能，而ASP.NET可以使開發人員建立強大的Web應用程式；.NET Compact Framework和MIT可以讓你建立靈活的PDA和手機使用者介面。瞭解你可以運用的工具以及使用者的需求是用.NET構建成功的使用者介面的關鍵。
關於作者:Robert Ericsson是位經驗豐富的軟體開發人員和專案經理，他主要致力於Microsoft技術的研究。Jason Cline是位軟體工程師，專門從事.NET Framework的研究。你可以通過dotnet@l10systems.com聯絡他們。
