我們要尋求一種避免直接寫代碼的應用程序配置和信息設置方法，我們已經 創建了多種不同的策略來存儲配置信息。而我們是要尋求一種正確的方法，我們 要不斷提高和改我們的想法，關於哪裡是放置這些信息的好地方。INI文件？這 是Windows3.1做的事，配置信息的結構是受限制的，而且在文件名上可能還會與 其它程序程序相沖突。注冊表？是的，是這個正確的想法，但它也有它的限制。 亂七八糟的程序可能會通過在注冊表裡寫一些錯誤信息來嚴重破壞計算機。正因 為寫注冊表存在危險，一個應用程序必須有管理員權限來寫注冊表的一部份。你 的所有用戶都會是以具有修改注冊表權利的管理員身份在運行嗎？希望不是，如 果你使用注冊表，而你的用戶不是以管理員身份運行的，在試圖讀寫注冊表時，將會得到一個異常和錯誤。
謝天謝地，還有很多更好的方法來存儲設置 信息，這樣你的程序可以根據用戶的選擇不同適應不同的行為，例如安裝參數，機器設置，或者其它任何事情。.Net框架提供了一個標准的設置位置，這樣你的 程序可以使用它來存儲配置信息。這些存儲位置是由應用程序特別指定的，而且 當程序執行的機器上的用戶被限制了權限時一樣可以有效的工作。
只讀 的信息是屬於配置文件的，XML文件控制應用程序中不同類型的行為；定義的結 構表指明了所有的元素和屬性，而這些都是.Net FCL從配置文件中分析出來的。 這些元素控制一些設置，例如正在使用那個框架版本，支持的調試級別(參見原 則36)，以及程序集的搜索路徑。有一個節點你是必須要明白的，那就是 aPPSettings部份，它可以同時應用與web應用程序和桌面應用程序。運行程序在 啟動時讀取這一節點的信息，它加載所有的關鍵字和值到一個屬於應用程序的名 字值集合(NameValueCollection)中。這是你自己程序的一部份，你可以添加任 何程序須要的值來控制程序行為。當修改配置文件時，也就修改了程序行為。
對於使用配置文件來說，ASP.Net應用程序比桌面應用程序的伸縮性稍靈 活一點。每個個虛擬目錄可以有一個自己的配置文件，這個文件被每個虛擬目錄 依次讀取，而每個虛擬目錄也就對應一個URL的一部分。The most local wins. 例如，這個URL： http://localhost/MyApplication/SubDir1/SubDir2/file.ASPx 可能被4個不同 的配置文件所控制。Machine.config最先讀取，其次是在MyApplication中的 web.config文件，接著是在SubDir1 和SubDir2中的web.config文件。而它們每 一個都可以修改前一個配置文件設置的值，或者是添加自己鍵/值對。你可以通 過這種配置繼承方式，來配置一個全局應用程序的參數選擇，而且可以限制一些 私有資源的訪問。web應用程序在不同的虛擬目錄中有不同的配置。
在桌面應用程序中，對於每個應用程序域只有一個應用程序程序配置文 件。.Net運行時在載入每個可執行文件時，為它創建一個默認的應用程序域，然 後讀取一個預先軍定義的配置文件到這個應用程序域中。默認的配置文件在與應 用程序運行時的同一個目錄中，而且就以<應用程序名>.<擴展名 >.config來命名的。例如：MyApp.exe可能就有一個名為MyApp.exe.config的 配置文件。aPPSettings部份可以用於創建你自己的鍵/值對到應用程序中。
配置文件是存儲一些控制程序行為的信息的最好的地方。但你可能很快 會發現，應用程序沒有API來寫配置文件信息。配置文件不是用於存儲任何有序 設置的地方。不要急著寫注冊表，也不要自己亂寫。這裡有一個更好的方法讓你 配置桌面應用程序。
你可能須要定義配置文件的格式，而且把配置文件 放到正確的地方。通過在全局設置上定義一些設置結構和添加公共的讀寫屬性，你可以很簡單的存儲和取回這些設置：
[ Serializable( ) ]
public struct GlobalSettings
{
// Add public propertIEs to store.
}
XML序列化來存儲你的設置：
XmlSerializer ser = new XMLSerializer(
typeof( GlobalSettings ));
TextWriter wr = new StreamWriter( "data.XML" );
ser.Serialize( wr, myGlobalSettings );
wr.Close( );
使用XML格式就意味著你的設置可以很容易的閱 讀，很容易的解析，以及很容易的去調試。如果須要，你可以對這些用戶設置進 行加密存儲。這只是一個使用XML序列化的例子，不是對象持久序列化(參見原則 25)。XML序列化存儲文件，不是整個對象樹。配置設置以及用戶設置一般不會包 含網狀對象，而且XML序列化是一個簡單的文件格式。
最後一個問題就是 ，應該在哪裡存儲這些信息。你應該在三個不同的地方放置配置信息文件。選擇 哪一個要根據配置的使用情況：全局，單用戶，或者單用戶且單機器。這三個位 置可以通過調用System.Environment.GetFolderPath() 而取得。你應該在 GetFolderPath()返回的路徑後添加上應用程序的詳細目錄。請格外小心的在所 有用戶或者機器范圍上填寫信息。這樣做要在目標機器是取得一些特權。
Environment.SpecialFolder.CommonApplicationData返回存儲信息的目 錄，這一目錄是被機器上的所有用戶所共享的。如果在一台機上使用的是默認安 裝，GetFolderPath(SpecialFolder.CommonApplicationData)會返回 C:\Documents and Settings\All Users\Application Data。存儲在這一目錄的的 設置應該是被機器上的所有用戶所使用的。當你要在這裡創建信息時，讓安裝程 序給你做或者以管理員模式進行。不應該在這裡寫一些用戶級(譯注：users級是 Windows裡的一個用戶組，權利比管理員小。)的程序數據。偶然可能會讓你的應 用程序在用戶機上沒有足夠的權限來訪問。
Environment.SpecialFolders.ApplicationData返回當前用戶的路徑，而且在網絡上被所有機器共享的。在默認安裝中，GetFolderPath (SpecialFolders.ApplicationData)返回 C:\Documents and Settings\<用戶名>\Application Data。每個用戶有他(或她)自己的應用程序數據目錄。當用 戶登錄到一個域是，使用這個列舉進入到共享網絡上，而且在網絡上包含了用戶 的全局設置。存儲在這裡的數據只由當前用戶使用，不管是從網絡上的哪台機器 登錄過來的。
Environment.SpecialFolders.LocalApplicationData返回 一個特殊的目錄，該目錄隊了存儲設置信息以外，同時也是一個用戶的私人目錄 ，它只屬於從這台機器上登錄的用戶。一般GetFolderPath (SpecialFolders.LocalApplicationData)返回：C:\Documents and Settings\<用戶名>\Local Settings\Application Data
這三個不同 的位置可以讓你存儲每個人的設置信息，給定用戶的信息，或者是給定用戶並給 定機器的信息。具體的使用哪一個取決於應用程序。但考慮一些明顯的例子：數 據庫鏈接字符串是一個全局設置，它應該存在在通用應用程序數據(Common Application Data) 目錄中。一個用戶的工作內容應該存在在應用程序數據 (Application Data)目錄中，因為它只取決於用戶。窗口的位置信息應該在本地 應用程序數據(Local Application Data)目錄中。因為它們取決於機器上的用戶 的屬性(不的機器可能有不同的分辨率)。
應該有一個特殊的目錄，它為所有應用程序的所有用戶設置存儲，描述頂層的目錄結構。這裡，你須要在頂層目錄結構下創建子目錄。.Net框架的System.Windows.Application類定義了一些屬性，這些屬性可以為你創建一些通用的配置路徑。Application.LocalAppDataPath屬性返回GetFolderPath(SpecialFolders.CommonApplicationData)+"\\CompanyName\\ProductName\\ProductVersion"的路徑。類似的，Application.UserDataPath和Application.LocalUserDataPath產生位於用戶數據和本地數據目錄下的路徑名，這一目錄包括公司，應用程序，以及版本號。如果你組合這些位置，你就可以為你自己公司的所有應用程序創建一個配置信息，或者為某一程序的所有版本，或者是特殊版本。
注意到了，這些目錄中我沒有提到過應用程序目錄，就是在Program Files下 的目錄。你決不應該在Program Files或者在Windows 系統目錄以及子目錄裡寫 數據。這些目錄要更高的特權，因此你並不能指望你的用戶有權利來寫這些數據 。
當在哪裡存儲應用程序的設置數據成為一個很重要的問題，就像每個 企業級用戶到家庭用戶所擔心的機器安全問題一樣時，把信息放在正確的位置就 意味著對於使用你的應用程序的用戶來說沒有折衷的辦法。你還是要給用戶提供 私人的感覺，用.Net的順序組合正確的位置，這樣可以很容易的給每個用戶一種 私有的感覺，而且不用折衷安全問題。
返回教程目錄
