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

Question

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

然后，UnitOfWork（UoW）模式。这是一种在Web上广告的模式，特别是与EF结合使用时。

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

示例方案：

我有一个MultiTenant网络应用程序。创建新Tenant时，创建Tenant的用户也需要存储为新创建的Tenant的用户。负责创建新Tenant并在当前案例中分配第一个User的类是Tenant类本身。如果某些内容失败，则Tenant和User都不应存储在数据库中。

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

有人（更喜欢这个领域的专家在实际EF解决方案中实际使用UoW）可以解释使用UnitOfWork而不是依赖DbContext的优势吗？

专家能否向我提供命名惯例？ TenantAndUserUnitOfWork以 long 打击我并免费进行解释（不是您在面向对象的世界中所期望的，或者我错了吗？）

Answer 1

  

UnitOfWork模式是否在EF应用程序中添加值？

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

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

• 我需要注册用户并为其创建个人资料。
• 我需要删除订单并注意用户已将其删除。
• ...

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

答案：是的，如果你想制作认真的软件。