c# - UnitOfWork 模式是否会在 EF 应用程序中增加值(value)？

Question

EntityFramework 允许我从 POCO 类创建表格。 Repository 模式 允许我在数据库概念之上创建一个抽象层，这样我就可以专注于实际应用程序的编程。

但是，UnitOfWork (UoW) 模式。这是一种在 Web 上广为宣传的模式，尤其是与 EF 结合使用时。

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

示例场景:

我有一个 Multi-Tenancy 网络应用程序。创建新的 Tenant 时，创建 Tenant 的用户也需要存储为新创建的 Tenant 的用户。在我当前的案例中，负责创建新的 Tenant 并分配第一个 User 的类是 Tenant 类本身。如果出现故障，Tenant 和 User 都不应存储在数据库中。

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

有人(更喜欢在实际 EF 解决方案中实际使用 UoW 的该领域专家)可以解释使用 UnitOfWork 相对于依赖 DbContext 的优势吗？

专家也可以提示我命名约定吗？ TenantAndUserUnitOfWork 让我觉得很长 并且可以自由解释(这不是您在面向对象的世界中期望的东西，或者我错了吗？)

Answer 1

Does the UnitOfWork pattern add value in an EF application?

工作单元是表示域事务的好方法。那么，它是否为使用它的应用程序增加了值(value)(具有 Entity Framework 或任何其他底层存储方法)？

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

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

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

回答:是的，如果你想生产严肃的软件。