我正在創建一個3層應用程序。基本上，它會正確抽象3層系統中的數據庫層？
客戶端 - >（通過可選的服務器 是瘦客戶機） - >業務邏輯 - > 數據庫層
，基本上使得它，以便從未有任何跳躍周圍。因此，我希望所有的SQL查詢都在數據庫層。
那麼，現在我有點困惑。我做了幾個靜態類來啓動數據庫層，但我應該如何處理數據庫連接？我是否應該在任何時候創建一個新的數據庫連接，然後進入數據庫層，否則會浪費？每當你有一個ConnectionPool時，Connection.Open（）是否需要時間？
對我來說，業務層必須將IdbConnection對象傳遞到數據庫層纔是錯誤的。看起來數據庫層應該處理所有特定於DB的代碼。你怎麼看？如何在保持實用性的同時以正確的方式做到這一點？
由於ConnectionPool，每次訪問數據庫時都會打開一個新連接通常不成問題。
如果您可以重複使用，不留連接打開很長一段時間打開的連接，並且沒有冒着留下孤兒打開的連接，那麼它不會傷害重用打開的連接。 （我實際上將一個數據工具注入到所有訪問數據庫的類中，這主要是爲了單元測試的目的，但它也允許我可以選擇保持一個連接打開，以便多次調用數據庫。）
但再次，你不應該過多地關注打開/關閉很多連接。這是更重要你的DAL：
只有在需要時纔打開連接。 不要維護與數據庫的連接，這會浪費得多。 當然你的數據庫層會打開連接，林不知道爲什麼你認爲BLL將傳遞連接到數據庫。 BLL不知道數據庫（至少它不應該），它應該處理業務規則等。實際連接在db層打開。
這裏是展示BLL應該是什麼樣子的鏈接：
連接字符串本身應該僅僅是你的數據庫層類中的一個私有變量，你應該能夠拉連接字符串來自說一個web.config文件的信息。
是的，但它取決於應用程序。如果您每天運行一百萬條查詢，您將需要持續連接以避免不斷設置新連接的開銷。 – 2010-03-30 17:04:29
@Justin - 我更多的是試圖解釋BLL的功能。你所說的是另一個話題。更多的信息將需要從OP。 – JonH 2010-03-30 17:06:00
您可以創建一個類（或類的名稱空間，具體取決於大小）來託管數據庫層。在您的數據庫類中，您應該只使用數據庫層中的連接池。該池將在任何給定時間保持n個連接對數據庫開放的連接數，因此您可以使用其中一個池連接運行查詢，而不會產生大量開銷。
有了這個，你的數據庫層應該提供一個業務層可以調用的公共方法的「API」。這些方法都不應公開數據庫連接對象 - 這些細節在數據層內部。
然後從您的業務層，每次需要運行查詢時調用數據庫層的「API」。
這有幫助嗎？
可以在每次進入數據庫層時創建並打開一個新連接，並在完成後立即關閉連接。 .Net/Sql Server可以很好地處理連接池，使其成爲可行的方法。
您也是對的，您不會從業務層傳入連接字符串。這應該是數據層的私有（但可配置）成員。
傳統上，單獨的「數據訪問層」提供用於檢索和提交數據的數據庫上下文。有幾個衆所周知的模式，比如Repository。 ADO.NET實現了其他幾個，比如Provider。
實體框架和LINQ to SQL也是進一步封裝和簡化數據層隔離的好選擇。
有沒有什麼特別的原因讓你不使用ORM？我發現它可以節省20-50％的開發時間，而無需手工編寫SQL查詢，更不用說連接管理，緩存和所有其他方面的好處了。 – 2010-03-30 17:03:46
因爲這是一個微不足道的過程，讓我們的舊項目與SQL的垃圾負載並把它帶到新的項目。 – Earlz 2010-03-30 17:05:30
以下任何答案都可以幫助你解決問題嗎？ – JonH 2010-03-30 18:07:37