我通常將我的連接字符串存儲在web.config或我的Visual Studio項目的應用程序設置中。我目前正在處理的應用程序會進行大量的數據訪問,這意味着它會每次查找連接字符串。我應該將連接字符串放入緩存中,還是應該考慮將整個SqlConnection對象存儲在緩存中,以消除始終打開和關閉它們的需要?你在哪裏存儲數據庫連接字符串?
更新:好像共識是存儲在配置文件中的連接字符串,並保留緩存在ADO.NET
我通常將我的連接字符串存儲在web.config或我的Visual Studio項目的應用程序設置中。我目前正在處理的應用程序會進行大量的數據訪問,這意味着它會每次查找連接字符串。我應該將連接字符串放入緩存中,還是應該考慮將整個SqlConnection對象存儲在緩存中,以消除始終打開和關閉它們的需要?你在哪裏存儲數據庫連接字符串?
更新:好像共識是存儲在配置文件中的連接字符串,並保留緩存在ADO.NET
我將不緩存連接對象,這將擊敗內置的連接池 - ADO.NET將處理連接(假設你實例化和關閉它們)有效地本身。
至於連接字符串本身,你不應該,如果你從連接加載它需要緩存它 - 在.NET 2.0框架的連接管理器對象加載配置到內存中,當你第一次訪問,所以沒有重複訪問文件系統。
的信任手保持它在配置文件中。使用由NHibernate或Linq to Sql等工具提供的健壯數據訪問策略。
從我能記得的.config文件的內容被保存在內存中...無論如何,我會回到你身邊。
編輯:什麼HE說
我通常將連接字符串緩存在我的應用程序中的全局配置對象中。該值在程序執行的從那裏以往任何時候都存儲在開始裝起來 - 文件,加密文件,配置文件等ADO.NET是在緩存連接對象數據庫非常好,所以我不會緩存SqlConnection對象。
web.config被高速緩存。但即使不是,請不要忘記,ado.net維護一個連接池 - 每次調用數據庫時都不會打開一個新的連接。
一個可能的解決方案: 存儲初始加密連接字符串(在Web.Config或App.Config中)的登錄,允許只運行一個存儲過程進行身份驗證。比從存儲在分貝一個配置表加密的值動態地切換的登錄。