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

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

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

我正在使用多个存储库，并且确实需要以原子方式提交内容。然后我在每个 UoW 示例中看到他们实现了一个方法 SaveChanges ，该方法不执行任何其他操作，然后将调用传递给 DbContext.SaveChanges 。感觉有点薄，所以我可能没捕获重点。或者 UnitOfWork 只不过是一个 DbContext 包装器？

示例场景:

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

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

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

专家也可以提示我命名约定吗？ TenantAndUserUnitOfWork 让我印象深刻，而且可以自由解释(这不是您在面向对象世界中所期望的，还是我错了？)

最佳答案

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

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

我需要注册一个用户并为其创建一个配置文件。

我需要删除一个订单并通知用户它已被删除。

...

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

回答:是的，如果您想制作严肃的软件。

关于c# - UnitOfWork 模式是否在 EF 应用程序中增加了值(value)？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/14540174/