如何使用 DbContextScope 在 saveChanges 之后检索数据库生成的 ID

Question

我计划创建一个具有以下层的应用程序，并使用 Entity Framework 作为我的 ORM：介绍：与我的问题无关。业务：在这一层我打算只使用 DTO 对象。我想让我的业务层与任何数据库实现细节分开，因此与实体的所有交互都在 DAL 层中完成。DAL：在这一层中，我计划拥有所有实体框架代码和实体。我将介绍可由业务层调用的存储库。这些存储库期望 DTO 对象作为输入，并返回 DTO 对象作为输出。DTO和实体之间的映射是在这一层完成的。我看了很多在线教程和与实体框架相关的文章，并遇到了DbContextScope项目，它似乎是控制“业务事务”并确保提交或回滚所有相关更改的非常好的解决方案。请参阅 GitHub：https ://github.com/mehdime/DbContextScope该 GitHub 存储库中的演示包含一个在数据库中创建新实体的场景。当我尝试将该场景映射到我的图层时，它似乎是这样的：业务：为要存储的实体创建具有属性值的 DTO。在传递 DTO 的 DAL 层中创建新的 DbContextScope 和调用存储库。DAL：存储库将 DTO 映射到实体并将其添加到实体框架的 DbContext 中。业务：在DbContextScope上调用 SaveChanges() 方法，后者又在 Entity Framework 的 DbContext 上调用 SaveChanges()。在演示中，所存储实体的 ID 在创建 DTO 时已知。但是，我正在寻找一种方法来确定在业务层中调用 DbContextScope 上的 SaveChanges() 方法后由 EF 自动分配的 ID。由于此时我处于业务层，我无法再访问该实体，因此我无法再访问该实体的 ID 属性。我想我只能通过查询数据库中刚刚创建的记录来确定 ID，但这只有在原始 DTO 包含一些我可以用来查询数据库的唯一标识符时才有可能。但是，如果我的 DTO 中没有可用于查询的唯一值怎么办？关于如何解决这个问题的任何建议，或者您是否推荐我的图层的替代方法？（例如，也在业务层中使用实体——尽管这听起来是错误的做法）

Answer 1

我尽可能使用 Mehdime 的上下文范围，因为我发现它是一个工作单元的出色实现。我同意卡米洛关于不必要的分离的评论。如果 EF 被信任用作您的 DAL，那么它应该被信任按设计工作，以便您可以完全利用它。

在我的例子中，我的控制器管理 DbContextScope，我将存储库模式与我的实体的 DDD 设计结合使用。存储库充当与 DbContextLocator 作用域和定位的上下文交互的看门人。在创建实体时，存储库充当带有“Create{X}”方法的工厂，其中 {X} 代表实体。这确保提供了创建实体所需的所有必需信息，并且实体在返回之前与 DbContext 相关联，从而保证实体始终处于有效状态。这意味着调用上下文范围的 SaveChanges 时，绑定服务会自动为实体分配 ID。ViewModels / DTOs 是控制器返回给消费者的东西。您还可以选择在 DbContextScope 的边界内调用 DbContext 的 SaveChanges，这也会在上下文范围 SaveChanges 之前显示 ID。当您想要为松散耦合的实体获取 ID 时，这更像是一种非常极端的情况。（无 FK/映射关系）存储库还为“删除”代码提供服务，以确保管理所有相关实体、规则等。虽然编辑实体属于实体本身的 DDD 方法。确保所有相关实体、规则等都得到管理的代码。虽然编辑实体属于实体本身的 DDD 方法。确保所有相关实体、规则等都得到管理的代码。虽然编辑实体属于实体本身的 DDD 方法。

可能有一个更纯粹的论点，即这种将域或 EF 特定问题的细节“泄漏”到控制器中，但我个人的观点是，在服务层的有界上下文范围内“信任”实体和 EF 的好处远远大于一切。它更简单，并且允许您在代码中有很大的灵活性，而不需要传播近乎重复的方法来为消费者提供过滤数据，或复杂的过滤逻辑来从服务层“隐藏”EF。我遵循的基本规则是实体永远不会在其上下文范围的边界之外返回。（无需分离/重新附加，只需选择到 ViewModels，并根据传入的视图模型/参数管理实体上的创建/更新/删除。）

如果您可以提供更具体的问题/示例，请随时添加一些代码概述您看到这些问题的地方。