Question

我目前已经制作了一个包含数据库连接和事务的UnitOfWork实现。

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

   uow.SaveChanges();
}

如果在释放uow之前未调用SaveChanges，则会调用回滚。

让uow处理连接和事务都是一个糟糕的设计选择吗？

假设我有一个ASP.Net MVC网站，其中大部分操作只是从数据库中获取信息。创建/提交实际上没有在数据库中执行任何操作的事务是否存在性能损失？

Answer 1

如果要实施UoW，那么SaveChanges应该是唯一使用连接和事务的地方。 UoW将收集所有必须执行的命令，并在调用SaveChanges时在事务中执行它们。

Answer 2

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

Answer 3

您是否自己实施了工作单元（我假设您已经这样做了）。研究如何使用ADO.NET EF和Repository模式。

有一个大阵营认为任何数据库操作都应该包含在事务中。您应该确保在事务中包装任何Inserts / Updates / Deletes。

话虽如此，请在Using Block中包装任何实现IDisposable的数据库对象。

UnitOfWork与数据库连接

3 个答案: