優點和DAL

Question

使用Singleton模式的缺點我都要求使用Singleton模式實現DAL，但我認爲它很難池中的連接，使用transactions..etc

我想知道的利弊並且還想知道集中連接的最佳方式，因爲我正在開發的網站可能有超過500個併發用戶。

DB Server是Oracle 10g。

DAL使用企業庫3.1

Answer 1

單身模式對於DAL很有用 - 我在自己的企業Web應用程序（數百個用戶和20多個單例類中的超過2000個方法）中使用了這種模式。連接池的確由ado.net和sql server本身處理得最好。如果你想要有多種類型的後端服務器，那不是問題。即使使用單例模式，您可能也需要一個集中的數據訪問類，它處理實際直接調用數據庫的具體細節（使用參數，文本/過程名稱，憑證/連接字符串全部傳入）。

在我的情況下，單一的每個方法與我的數據庫中的存儲過程1：1相對應。這基本上爲每個存儲過程創建一個C＃「前端」鉤子，以便它們可以在語法上與C＃代碼幾乎一樣被調用。它可以直接調用DAL。我有多個單身人士，因爲大量的SP有問題。每個SP都有一個前綴，比如Development_，或者Financial_，或者Organization_或者其他。然後我有一個對應於每個類的單例類，如Development，Financial或Organization。因此，在C＃中的組織_ViewData是一個名爲ViewData的方法，名爲Organization的單一類。

這當然只是其中一種方式，但我發現在過去六年中與多個開發人員和大量代碼一起工作得非常好。主要的是一致性是關鍵。如果一個前端程序員正在查看你的一個單身經紀人的方法名稱，那應該告訴他們到哪裏進入數據庫端。這樣，如果出現問題，或者如果有人不得不通過代碼搜索來試圖瞭解它，那麼需要做的跟蹤就會少一些。

Answer 2

我不知道DAL但單件模式是讓全球的數據，同時保持良好的封裝性的好方法。

Answer 3

在DAL中爲數據庫連接工廠使用單例很常見。它可以讓您更輕鬆地插入工廠的不同實現，而無需更改大量代碼。很多人似乎並不喜歡單身模式，但我認爲它對這種類型的事情起作用。

Answer 4

連接池的最佳實踐是不要自己實現它，而是讓ADO.NET框架來處理它。

可以將連接池選項設置爲連接字符串內的參數。然後，每個使用該字符串打開的連接都將從框架實施和管理的連接池中提供。當您關閉或處置OracleConnection時，底層連接不會被銷燬，而是會返回到池中。

這說明如下： http://msdn.microsoft.com/en-us/library/ms254502.aspx

關於普遍使用的單身：我用它們來包裝數據訪問層，並且它一直運作良好。

請注意，事務僅適用於特定連接，而不適用於整個數據庫。這意味着您可以運行多個線程，並且每個線程都可以通過獨立事務讀取和寫入數據庫，從而爲每個線程使用單獨的OracleConnection實例。

Answer 5

如果你使用單例或者不使用，我認爲你不會有性能差異，因爲你仍然可以同時在同一個方法上運行多個線程。如果你注意不要在所有線程中共享內部字段，一切都會運行良好。

最後，管理連接池的類需要是線程安全的，並且最終會生成一些會影響性能的鎖，但它們都是需要的。 （它是在框架內部製作的，無論如何你都不能改變它的行爲）

如果你決定不使用單例，確保你的DAL實例是輕量級的，因爲這可能會有所作爲，但通常它不是。

注意：在談論連接池時，您必須注意的唯一重要的事情是遵循「開放遲，關閉早」的模式。這意味着儘可能延遲連接的打開，並在完成所有需要的操作後儘快關閉連接。

使用這個魔法規則建立了所有的系統後，您可以使用連接字符串參數來改變某些池選項（初始大小，最大大小，...）

Answer 6

對於在DAL中使用單身人士，我有點不安。如果我想使用多個數據庫後端怎麼辦？也許我想使用MsSQL發票，但使用Active Directory進行身份驗證。或者，也許我想用MySQL作論壇帖子，但PostgreSQL用於地理聚類（對我來說更現實一些，呵呵）。當我無法將模擬數據庫連接傳遞給測試時，Singleton Interfaces可能使測試數據庫層更具挑戰性。