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数据库连接

回答

相关问题