UnitOfWork vs數據庫連接

我目前已經做了一個包裝數據庫連接和事務的UnitOfWork實現。UnitOfWork vs數據庫連接

using (var uow = UnitOfWorkFactory.Create()) 
{ 
    // do db operations here through repositories 

    uow.SaveChanges(); 
}

如果SaveChanges的UOW得到處理之前還沒有被稱爲回滾將被調用。

讓uow處理連接和事務都是不好的設計選擇嗎？

假設我有一個ASP.Net MVC網站，其中大部分操作只是從數據庫中獲取信息。創建/提交的事務在數據庫中實際上沒有做任何事情會有性能損失嗎？

來源

2011-04-19 jgauffin

你是否發現總是創建一個事務是否有問題，即使只是'SELECT'語句？我不熟悉後端編程，這是我在SQL書中讀到的內容 - 「在事務中執行SELECT語句可以在引用的表上創建鎖，從而阻止其他用戶或會話執行工作或讀取數據「_ – Axel 2016-10-19 15:05:53

如果你想實施UoW，那麼SaveChanges應該是唯一一個使用連接和事務的地方。當調用SaveChanges時，UoW將收集所有必須執行的命令並在事務中執行它們。

來源

2011-04-19 08:59:07

總是開始的事務呢？我不熟悉後端編程，這是我在SQL書中讀到的內容 - 「在事務中執行SELECT語句可以在引用的表上創建鎖，從而阻止其他用戶或會話執行工作或閱讀數據「 – Axel 2016-10-19 15:01:41

UoW是域特定的。我有或多或少的相同的實現，直到有人指出，因爲數據庫訪問不應該真的影響你的域名。

所以我最終分裂了責任。由於我的UoW確實使用了需要連接到數據庫的存儲庫，我仍然需要連接。

因此，對於在這裏我不需要UOW情況下，我都會有這樣的：

using (DatabaseConnectionFactory.Create()) { ... }

對於事務：

using (var connection = DatabaseConnectionFactory.Create().BeginTransaction()) 
{ 
    // do stuff 

    connection.CommitTransaction(); 
}

如果我需要一個UOW（通常與交易）：

using (var connection = DatabaseConnectionFactory.Create().BeginTransaction()) 
using (var uow = UnitOfWorkFactory.Create()) 
{ 
    // do stuff 

    connection.CommitTransaction(); 
}

HTH

來源

2011-04-19 09:10:14

你是否自己實施了工作單元（我假設你做過）。研究使用ADO.NET EF和Repository模式。

有一個大陣營覺得任何數據庫操作都應該包含在一個事務中。您應該確保在事務中包裝任何插入/更新/刪除。

也就是說，將任何實現IDisposable的數據庫對象包裝在Using塊中。

來源

2011-04-20 15:27:31

UnitOfWork vs數據庫連接

回答

相關問題