我应该如何为 Blazor 配置实体框架生命周期？答案

【问题标题】：How should I configure the Entity Framework Lifecycle for Blazor?我应该如何为 Blazor 配置实体框架生命周期？
【发布时间】：2021-04-09 19:55:47
【问题描述】：

我正在开发一个广泛使用实体框架的 blazor 应用程序。我做了一些阅读，表明DbContext 的默认生命周期不适用于 Blazor（请参阅https://stackoverflow.com/a/66817764/14024210）。但是，我不打算将上下文直接注入到我的组件中，而是使用注入上下文的服务。只要上下文存在于我的主要表单组件的生命周期中，就应该没有问题。

我应该将上下文和服务都配置为瞬态吗？我的理解是，每当组件接收到上下文时，这都会提供两者的新实例。
我的服务是否需要实现IDisposable 才能正确处理？或者如果它唯一的依赖是DbContext，这不是必需的吗？

简而言之，我想正确实现 DbContext 设计的“工作单元”概念。

【问题讨论】：

标签： entity-framework entity-framework-core blazor blazor-server-side lifecycle

【解决方案1】：

当您使用 Blazor WebAssembly 时，这会在服务器上自行解决：每个 API 调用都有一个完全可用的生命周期，可用作 Scope。

对于 Blazor 服务器端，使用 DI 管理 DbContext 只需 not appropriate。

推荐的方法是为每个操作创建一个 DbContext，并使用 using(...) {...} 块对其进行管理。您可以注入 DbContextFactory 来帮助进行配置。

每个组件使用一个 DbContext 可能很诱人，但这会导致上下文保持打开很长时间并增加服务器上的内存使用。这不会很好地扩展，也不鼓励使用服务。

所以，我会为每个 Service 方法使用一个 DbContext。

【讨论】：

谢谢！这是有道理的，但它也引入了断开实体的问题。例如，我有一个 Employee 对象，它是我的主模型的子对象。目前，DbContext 的共享实例允许对此进行跟踪。当我使用 DbContextFactory 时，这些实体不再附加到上下文并尝试插入它们。虽然我总是可以将它们的状态设置为分离，但这不会那么干净。或者，我可以限定组件的生命周期，并确保 DbContext 得到适当的处理。
是的，这很方便。但是你的 UI 就是你的 DAL。您将为可维护性和可测试性付出代价。独立的实体（数据层之外）更干净，恕我直言。