c# Winform應用程式開發規範

1 前言

一直想寫一編關於Winform UI正常化開發的文章，客戶總是抱怨我們程式介面不美觀，操作不方便。作為程式開發人員，工作重點往往在商務邏輯實現上，或許他們可以設計很好的演算法，將系統的資源佔用率降的更低，使運行效率提得更高。但這些高品質的邏輯代碼的使用者是看不到的；使用者衡配量序的好壞，除了運行結果正確與否外，非常重要的一方面就是介面是否規範，操作是否方便。

寫這篇文章之前在同學齊的QQ空間中看到關於WPF/XAML技術的一些討論。剛接觸WPF/XAML這個字眼的時候，竟然不知所云，後來與他聯絡才得知是微軟在.Net3.5中推出的一套構建應用程式UI全新的技術體系。技術的更新速度實在令每個程式員汗顏，每次當我們深入的探討某技術時，首先面臨的就是該技術即將淘汰的問題。因此我們在下面的討論中盡量避免各種原則的技術實現細節。

關於B/S和C/S。BS作為當今業界流行的應用程式體系確實給使用者和開發帶來了諸多方便之處。但是不是BS就能完全代替CS呢？從我們多年的實際應用開發經驗中得知，答案是否定的。BS體系由HTML發展而來，而HTML最初的發明者沒有預料到瀏覽器作為應用程式體系中的用戶端來實現當前如此複雜的功能，儘管後來仍然有很多技術（諸如JavaScript，Web2.0等）擴充到當前體系中來，但仍不能使瀏覽器做到具有像Winform程式一樣豐富的使用者互動效果。當一套應用程式中如果用戶端數量可預知情況下，我們應當以CS結構來實現應用系統。

2 Winform開發一般遵循的原則

2.1 表單類型

我們把UI理解成表單以及表單上使用者的互動規則。表單主要包括主介面類型和對話方塊類型兩種。

主介面指應用程式啟動後最主要的介面，其生命週期一般與應用程式保持一致。通過菜單或按鈕的形式調用其它子介面和執行功能。一般由以下幾個部分組成。 標題列，功能表列，工具列，目錄欄，工作區，資訊輸出區（欄）。此外很多應用程式中又增加一些漂浮的子表單以面板的形式附加到主介面中。

對話方塊一般指應用程式中具有返回結果的表單。一般表現為模態表單，包括資訊展現部分，資訊輸入部分和結果選擇按鈕三部分組成。

此外，UI部分除了主表單和對話方塊外還有浮動表單，托盤菜單等方式與使用者互動。

2.2 表單設計原則 2.2.1 IDE是典範

不知道如何做介面，就去模仿Visual Studio。

程式員不是美工，不可能要求程式員像美工一樣用Photoshop為應用程式設計UI表單，儘管有很多程式員會使用Photoshop，甚至擅長於平面設計，但他們不是專業的，專業的平面設計和程式設計是完全不同的工作。也並非所有的應用程式都需要用專業的平面設計軟體做出來的介面。IDE即是如此，IDE一般由作業系統提供的最基本的控制項和經過封裝的控制項來構成，不同的IDE封裝的控制面板大致相同。典型的例子是Delphi和Visual Studio .Net。

對話方塊一般指應用程式中具有返回結果的表單。一般表現為模態表單，包括資訊展現部分，資訊輸入部分和結果選擇按鈕三部分組成。

此外，UI部分除了主表單和對話方塊外還有浮動表單，托盤菜單等方式與使用者互動。

2.2 表單設計原則 2.2.1 IDE是典範

第一種表單一般固定尺寸大小。結果按鈕置中，第二種和第三種可以是Sizeable的表單，結果按鈕需要設定Anchor值來保持視窗大小更改後離視窗邊框的距離。

注意視窗結果按鈕的配對情況，一般是 Yes 和No， OK和Cancel配對使用，OK和Close也常用。但如過Yes和Cancel配合就不合時宜了。

此外，還應當給對話方塊指定Accept Button和 Cancel Button，Accept Button是表單預設的按鈕，當按斷行符號鍵時將代替滑鼠點擊該按鈕，同樣點擊Cancel Button和按Esc鍵效果是一樣的。

按鈕大小應該用滑鼠在表單設計器上單擊產生的預設尺寸，除非按鈕上文本太長否則不應該調整按鈕的尺寸大小。這樣做的好處就是系統中所有按鈕大小保持一致。以滑鼠拖拽的形式“畫”出來的按鈕，很難保證每次畫的尺寸都一樣。

2.2.4 Tab鍵次序

Tab鍵次序問題非常容易被忽視，UI開發經常遇到這種問題：本來介面上有若干文字框供使用者輸入資訊，後來因為需求的變更需要增加一個項插入到某個文字框之前，此時問題就隨之而來，IDE對輸入控制項的Tab值不會因為其上下左右排列次序自動產生，而是與輸入控制項的先後建立次序一致，因此在程式運行時會出現Tab定位輸入框“跳格”，這就給使用者帶來極大的不便，甚至造成錯誤的輸入。

由此可見，在UI設計時一定要注意輸入控制項Tab鍵次序問題。

2.2.5 快速鍵

以下幾種情況必須用快速鍵操作程式：膝上型電腦沒有可能沒有外接滑鼠，某些使用者熱衷鍵使用鍵盤，專業的操作人員為了提高工作效率不使用鍵盤。因此菜單和按鈕要有快速鍵。大部分Winform開發工具中只要設定菜單或按鈕的Text屬性包含 號“&”+ 字元形式的為本即可。例如：“增加（&A）”在運行期就是“增加(A)”,使用快速鍵為“Alt+A”。

2.2.6 INI檔案儲存預設值

應用程式若要提高使用者的工作效率，必須盡量減少使用者重複性工作，輸入類控制項（文字框，複選框等）應當遵循具有預設值的原則，預設值分為兩種，高頻值和上次輸入值。高頻值實現較簡單，只要根據實際需求設定輸入控制項的預設值為高頻值即可，亦可寫程式實現高頻值的智能選取（類似中文IME功能），但是筆者不提倡。

上次輸入值一般由INI檔案進行儲存，當表單對象建立時，讀取INI進行載入儲存到檔案中的值。操作INI檔案的具體實現可以參閱相關資料。在此需要注意的只有一點，儘可能早的儲存INI檔案。一般當確定按鈕點擊後實現其他商務邏輯之前，首先儲存INI檔案，這樣可以避免後面因為商務邏輯異常而造成INI檔案儲存被取消的可能。也有人習慣在表單對象的析構方法中儲存INI，這就更不提倡了。在後來的語言中對象的釋放越來越不可控，很難知道什麼時候才能被調用，我們應盡量不去在析構方法中編寫功能代碼。

ComboBox控制項預設值不設定情況下索引為-1而不是0，使用時一定要確定它是否可編輯，如果類似選擇數字字典的形式，那麼它一定是不可編輯的，如果不設定其類型屬性使其可編輯，那麼使用者在實際操作過程中可能直接輸入字串，顯然這是錯誤的。

2.2.7 右鍵菜單

右鍵菜單多用於容器類控制項，通常用於對容器控制項中包含的選中態元素進行操作，右鍵菜單一般不包含複選類功能表項目，因為右鍵菜單預設情況下是不可見的。

2.2.8 避免重複嵌套面板

不管是GroupBox，Panel，還是TabControl作為容器控制項不應該重複嵌套太多。GroupBox包含RadioButton時，假如表單只有一組RadioButton則不使用GroupBox。

2.2.9 UI開發異常處理

目前主流的Winform開發工具中，都包含了異常處理功能。比如點擊某個按鈕出現異常時，應用程式並不退出，而是將異常資訊以對話方塊的形式提示使用者，並終止異常後的邏輯處理。因此在Winform程式中異常捕獲語句除非有特殊的處理語句和拋出自訂異常外，一般不建議使用異常處理代碼。例如以下虛擬碼：

Try {

// To do something ….

.}

Catch (Exception ex)

{

//這裡必須有類似MessagBox之外的處理語句 或者throw 新的異常類對象， 比如關閉檔案，關閉資料庫連接等。

MessageBox.Show(“程式失敗/n” + ex.Message);

}

假如必須使用MessageBox類的代碼重新封裝對使用者的資訊提示，那麼必須注意不要把原來異常的資訊丟失。這些異常資訊是程式維護和開發人員所關心的。如果客戶不能接受這類資訊的展現，則以輸出日誌形式將異常資訊儲存到存放裝置。

當然還有一類代碼結構確實是捕獲異常但不處理的情況，此時不適合上述原則。

3 結論

Winform開發過程中需要遵循的原則還有很多，我們沒辦法用有限的篇幅將所有情況一一列舉。總的來講，就是要使應用程式與作業系統的UI保持一樣的風格和習慣，只有如此才能使使用者更願意使用和操作，真正達到用資訊技術的力量服務於各行各業的目的。

本文來自CSDN部落格，轉載請標明出處：http://blog.csdn.net/xiongxuanwen/archive/2008/07/28/2724440.aspx