關於connection string應該存放在哪裏 有許多不同的方法 每個都有自己的使用場合 根據MSDN和我以前編程的經驗 總結/摘錄了壹篇文章 希望對大家有所幫助 ?
在程序中要存儲connection strings 我們有不少的選擇的 每壹種方法都有自己的優缺點 特別是在靈活性和安全性上 當然 很多人就直接把connection strings寫在了程序裏 這樣雖然效率提高了壹些 可是實在是非常不方便將來的修改和配置 所以並不是壹種推薦的行為 ?
在選擇connection strings存儲方式時 感覺最重要的是安全性和易配置性 其次就是性能 在各類資料中 我們可以看到 存儲的方式主要有 ? ）程序配置文件 例如asp net中的web config文件? ）windows註冊表中? ）UDL文件? ）在+的catalog中（只用於serviced ponent）?
下面 我們逐個來討論壹下這幾種方法的優缺點 ?
）使用XML程序配置文件? 我們可以使用<appSettings>來把 connection string存儲在程序配置文件的custom settings部分 ? <configuration>? <appSettings>? <add key= DBConnStr value= server=(local);Integrated Security=SSPI;database=northwind;username= ;password= /> </appSettings>? </configuration>?
優點 ? a）很明顯 容易分發 connection string可以跟隨 NET的xcopy機制極其簡單的deploy ? b）易編程性 我們可以使用 ConfigurationSettings 中的AppSetting來讀取connection string? using System Configuration;? private string GetDBaseConnectionString()? {? return ConfigurationSettings AppSettings[ DBConnStr ];? }? c）在ASP NET中使用的話 可以自動更新 也就是說 如果壹個管理員修改了web config中的connection string 下壹次這個string被訪問是 修改後的內容會被使用 這點在web編程中非常實用 ?
缺點 ? 安全性 雖然ASP NET中已經明確寫了帶 config後綴的文件是不能被客戶訪問的 並且NTFS文件系統可以用來進壹步加強安全性 在web server中用明文來存儲connection string還是讓人覺得不爽啊 幸運的是 MS還提供了在配置文件中用encrypted方式存儲的辦法 這下基本上就OK樂 ?
）使用UDL文件? OLE DB NET Data Provider支持在connection string中使用UDL文件 具體方法可以參考KB Q HOW TO: Use Data Link Files with the OleDbConnection Object in Visual C NET 不過要註意的是這種方法SQL Server NET Data Provider不支持 ?
優點 ? 這也是壹種比較標準的方法 特別是妳以前就壹直用UDL ? 缺點 ? a) 性能 每次connection打開時都需要去讀取和分析UDL文件 ? b) 安全性 UDL文件是以明文的方式存放的 我們只能通過NT的文件系統設置它的訪問權限 ? 要註意在ASP NET中 要保證ASP NET跑的賬號有讀的權限 並且 註意不要把UDL文件放在虛擬目錄中 不然它有可能會被客戶下載
）使用註冊表? 當然我們也可以在註冊表中增加壹個鍵來存儲connection 但是這樣比較難以分發 ?
優點 ? a) 安全性 我們可以對註冊表的鍵使用ACL來控制讀寫權限 也可以考慮加密信息 ? b) 易編程性 NET也提供了很多類使我們可以容易的操作註冊表 ? 缺點 ? 分發 這種方式必須要把相應註冊表的修改也放入程序的分發過程中 壹定程度上就與 NET的xcopy不相符合了 ）使用自定義文件? 我們當然也可以自定義壹種文件格式來儲存connection string 但是這樣的話就沒有太多優點了 而且需要額外的編程 並且不容易分發 所以在很多場合下不太適用 ?
）使用+的catalog和construction arguments? 在使用到+的時候 我們也會把connection string存到+的catalog中 然後通過object construction string來傳遞給object +會在初始化對象時調用對象的construct函數 這種方法只適用於service ponents 當我們用到分布式transaction或object pooling時 我們就可以考慮這種方法 ?
優點 ? 管理 Admin可以非常容易的使用MMC配置connection string ? 缺點 ? 安全性 雖然我們可以通過+中的role來進行壹定的控制 + catalog 不是壹個非常安全的存儲地區 所以不要以明文的形式在其中存儲connection string ? 分發性 + catalog中的內容也必須和我們的程序壹起分發 這部分的內容比較多 這裏我就不壹壹詳述了 ?
lishixinzhi/Article/program/net/201311/15560