4

EntityFramework允许我从POCO类创建表。这Repository pattern允许我在数据库概念之上创建一个抽象层，以便我可以专注于对实际应用程序进行编程。

但是，UnitOfWork（UoW）模式。这是一种在 Web 上大肆宣传的模式，尤其是与 EF 结合使用时。

我正在使用多个存储库，并且确实需要以原子方式提交内容。然后我在每个 UoW 示例中，我看到他们实现了一个方法，该方法SaveChanges什么都不做，然后将调用传递给DbContext.SaveChanges. 感觉有点薄，所以我可能错过了重点。或者UnitOfWork仅仅是一个DbContext包装？

示例场景：

我有一个多租户网络应用程序。创建新的时Tenant，创建的用户Tenant也需要存储为新创建的用户Tenant。在我当前的情况下，负责创建新Tenant并分配第一个的类是类本身。如果发生故障，则不应将 和 存储在数据库中。UserTenantTenantUser

我现在处理的方式DbContext.SaveChanges是在所有操作成功执行之前不调用。

有人（更喜欢在实际 EF 解决方案中实际使用 UoW 的该领域专家）解释使用UnitOfWork过度依赖的优势DbContext吗？

专家能否也给我一些关于命名约定的提示？TenantAndUserUnitOfWork让我印象深刻并且可以自由解释（这不是您在面向对象的世界中所期望的，还是我错了？）

4

1 回答 1

3

UnitOfWork 模式是否会在 EF 应用程序中增加价值？

工作单元是表示域事务的好方法。那么，它是否为使用它的应用程序增加了价值（具有实体框架或任何其他底层存储方法）？

是的：一个好的软件应该在某些场景下实现原子操作。

  • 我需要注册一个用户并为其创建个人资料。
  • 我需要删除一个订单并通知用户它已被删除。
  • ...

一切都可以成为一个工作单元的一部分。

答：是的，如果你想制作严肃的软件。

于 2013-01-26T18:43:09.683 回答