工作角色中Entity Framework的DbContext生命周期

Question

我有一个工作角色，每秒钟与数据库进行一些工作。

当工作程序启动时初始化DbContext并在整个工作生命周期中使用它是否可行？

数据库连接是如何处理的？如果数据库离线然后再次上线会怎样？我仍然能够使用上下文吗？

- daramasala

---

过于宽泛，过于模糊。首先有两个问题。第一个问题在很大程度上取决于您在工作角色中所做的事情，涉及多少数据，持续多长时间。对于第二个问题，您应该查看使用Entity Framework时的连接弹性。 - Gert Arnold

@GertArnold 这个问题是关于在worker角色中使用单个DbContext实例的问题。其他问题是我在这方面担心的事情。“多久”-“在工作进程的整个生命周期内”。这意味着从VM启动到VM关闭，对吗？ “连接弹性”-您是否正在说连接丢失是短暂故障，并将由重试逻辑处理？ - daramasala

Answer 1

据我目前最好的了解，主要的DbContext抽象是工作单元。

每当需要时（即在context.SaveChanges()时），DbContext会打开和关闭数据库连接，因此数据库连接与上下文的范围无关。

从这个角度来看，现在我认为决定DbContext实例的范围需要考虑您的工作单元及其在内存中管理的实体。

例如，在我的问题中，通常情况下在工作进程的整个生命周期中使用单个上下文实例是没有意义的，因为：

1. 通常情况下，您将在每个角色调用中处理不同的实体。在这种情况下，上下文仍然需要将这些实体加载到内存中。

2. 随着时间的推移，上下文会在内存中管理越来越多的实体，这将导致性能问题（因为它扫描图形以寻找更改和要执行的任务）并最终导致内存问题。

3. 在内存中长时间保留实体会增加上下文中的实体和实际数据之间不一致的可能性。解决这些不一致可能会影响性能。

总之，在工作角色的整个生命周期中使用相同的DbContext实例可能是错误的。

为了确定DbContext的范围，需要考虑实施的工作单元。

- daramasala

Answer 2

我的建议是为每个操作创建、使用和销毁上下文...不要保留它。 一开始我很担心创建DbContext的成本，但答案是并不昂贵。

如果你试图重复使用DbContext实例，你也会很快遇到问题，因为它的内部状态模型将开始报告已经加载（更新或其他）的对象版本之间的冲突。

- Paul Carroll

---

我接受这个答案，因为它是正确的，但请注意在我的回答中也有更详细的解释。 - daramasala

本文建议在OnStart()中设置DbContext，并在Run()内使用：https://azure.microsoft.com/en-gb/documentation/articles/cloud-services-dotnet-get-started/#create-the-application-from-scratch。这并不意味着它是正确的，只是提供参考。 - lee_mcmullen

那篇文章似乎是在讨论Azure云存储，而不是本地磁盘上的Entity Framework。在一些处理网络通信的系统中，初始化连接并保持连接可能更可取，但这取决于需要完成的握手量（即HTTP不是这样工作的）。因此，我认为你需要小心，不要混淆概念，因为两者的骨干（因此操作）将大不相同。谢谢，保罗 - Paul Carroll