工作角色中的实体框架的DbContext生存期

我有一个工作者角色，每秒都会对数据库做一些工作。工作角色中的实体框架的DbContext生存期

工作人员启动时初始化DbContext并在工作人员的整个生命周期中使用它可以吗？

db连接是如何处理的？如果数据库脱机并重新联机，该怎么办？我仍然可以使用上下文吗？

2015-01-04 daramasala

太宽泛，太模糊。首先有两个问题。那么，第一个很大程度上取决于你在工作者角色中做什么，多少数据，多长时间。对于第二个问题，您应该查看与Entity Framework的连接弹性。 – 2015-01-04 23:26:31

@GertArnold问题是关于在辅助角色中使用单个'DbContext'实例。其他问题是我在这方面担心的事情。 “多久” - “整个职工的一生”。这意味着从VM启动到VM关闭，不是吗？ “连接恢复能力” - 你是否说连接丢失是一个暂时的故障，将由重试逻辑处理？ – daramasala 2015-01-05 05:54:30

我的建议是创建，使用和销毁每个操作的上下文......不要拘泥于此。我曾经担心起初是因为我不知道创建DbContext的代价有多昂贵，答案不是很多。

如果你试图保持重用的DbContext情况下，你也会遇到问题（非常快），因为它的内部状态的车型将开始报告冲突对已加载的对象的版本（更新等等）之前

来源

2015-01-15 01:29:11

我接受这个答案，因为它是正确的，但也请参阅我的答案中的扩展解释。 – daramasala 2015-01-18 07:17:47

本文建议在OnStart（）中设置DbContext并在Run（）中使用：https：//azure.microsoft.com/en-gb/documentation/articles/cloud-services-dotnet-get-started/#create-the - 应用 - 从划伤。这并不是说这是正确的，但仅供参考 – 2016-03-16 22:59:31

该文章涉及的是我能看到的Azure云存储，而不是本地磁盘上的Entity Framework。在一些处理网络通信的系统上，它可能比初始化连接并保持打开状态更可取，但这取决于需要完成的握手数量（即HTTP不以这种方式工作）。所以我认为你们应该小心，不要在这里混淆概念，因为骨干（和操作）在两者之间会有很大的不同。干杯，保罗 – 2016-03-17 22:20:58

就我目前所知，主要的DbContext抽象是工作单元。

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

这样看来，我现在认为要决定DbContext实例的范围，你需要考虑你的工作单元和它在内存中管理的实体。

例如，我的问题，通常使用遍及工人的生命周期单上下文实例就没有任何意义，因为：

通常你会在每个角色中调用不同的实体工作。在这种情况下，上下文将需要将这些实体加载到内存中。
加班时，上下文将管理越来越多的内存中的实体，这会导致性能问题（因为它扫描图寻找变化和事情）并最终导致内存问题。
将实体长时间保存在内存中会增加上下文中实体与db中实际数据之间不一致的可能性。解决这些不一致可能会降低性能。

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

根据您正在实施的工作单位来决定DbContext的范围。

来源

2015-01-15 12:36:53 daramasala

工作角色中的实体框架的DbContext生存期

回答

相关问题