在EF中，DbContext是否应该具有短的生命周期？

Question

7

我在我的服务器上有几个长时间运行的任务。它们基本上像是定时任务 - 定期运行。

它们都需要访问数据库，我使用Entity Framework进行访问。每个任务都使用一个DbContext进行访问。

在每次运行时，DbContext对象应该重新创建还是重复使用？

- Daron V

相关（如果不是重复的）问题：https://dev59.com/1m_Xa4cB1Zd3GeqPwxGQ?rq=1 - nemesv

2个回答

1

是的，DbContext 只应该在非常短的时间内存在。它实际上是您的工作单元。

每次使用它时都应该创建它。(好吧，你应该注入它，但这是另一个讨论 :-))

更新：好的，我承认“每次使用时创建它”可能会产生误导。我习惯于将上下文视为一个类的实例，该实例被注入并且仅在请求的生命周期内存在，因此我很难想到其他方式...@wiktor的答案绝对更好，因为它更正确地表达了您应该“尽早处理而不是晚处理”的想法。

- Paul D'Ambra

这不是真的（而且你回答中有些部分相互矛盾）。因为上下文是工作实现的一个单元，所以它应该存在的时间和需要完成该工作的时间一样长。在实际应用中，这可能需要很长一段时间。 - Dennis

整件事情都不是真的，@Dennis，还是你提到的那部分不真实？定义一个长时间... - Paul D'Ambra

1

分钟，小时...工作单位可以非常不同。如果这些单位与某些数据访问相关，则通常适合创建上下文，当工作开始时（例如，用户开始编辑某个文档），并在工作完成时处理它（用户按下“保存”按钮）。 - Dennis

所以您建议保留一个 DBContext 几分钟或几小时，以便用户可以编辑一些数据 - 天哪！ - Paul D'Ambra

我在我的评论中看不到任何建议。我想要解释的唯一一件事是，当处理上下文时可能没有精确的建议，因为有许多使用场景。唯一可以作为参考点的是工作单位的持续时间。 - Dennis

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Wiktor Zychla · Accepted Answer

我应该说“这取决于情况”，因为可能存在两种答案都是合理的情况，但最合理的答案是“只要不再需要，就应该立即释放上下文”，实际上意味着“尽早释放而非拖延”。

这种答案所带来的风险是，新手有时会得出结论，上下文应该尽可能经常被释放，这有时会导致我审查代码时发现连续的“using”块，每个块都创建一个上下文，在其中执行一两个操作，然后释放，并且下一行又出现了另一个上下文。当然，这也是不推荐的。

对于Web应用程序，自然生命周期与Web请求的生命周期相关联。对于系统服务/其他长时间运行的应用程序，生命周期策略之一是“每个业务流程实例”/“每个用例实例”，其中业务处理/用例实现定义了分离上下文实例的自然边界。