实体框架长期数据上下文与短期数据上下文 [关闭]

Posted 2023-04-13

【中文标题】实体框架长期数据上下文与短期数据上下文 [关闭]

【英文标题】：Entity framework long living data context vs short living data context [closed]

【发布时间】：2017-04-18 13:49:19

【问题描述】：

我想知道在以下两个示例之间使用 C# 和 SQL Server（实体框架）的最佳实践是什么：

1- 每次您想使用 SQL Server 时打开连接并在之后立即关闭它？ （我使用实体框架 using 语句）

2- 打开一次连接并在所有需要完成的任务需要的时候保持连接，即使有代码不需要打开 SQL 连接来运行？ （在这种情况下，我会自己控制上下文而不使用 using 语句）

我知道这个问题并不复杂，但我仍然是数据库和编程领域的新手。

非常感谢您的回答！

【问题讨论】：

取决于"as long as needed for all the tasks that need to be done" 的含义。什么任务？你实际上在做什么？你能提供例子吗？

这个问题太宽泛而且基于观点 - 没有一个正确的答案。

我不同意 too broad 的说法。众所周知，EF 在应用大量更改时会减慢其上下文（由于更改跟踪器）。充其量这将是重复的，但这应该传达给 OP。

示例：***.com/questions/5943394/…、weblog.west-wind.com/posts/2014/Dec/21/…、***.com/questions/10103310/…

备案；这将争辩说，短暂的环境是首选。顺便说一下，适用于所有与内存管理相关的问题。除非有正当理由（未给出），否则所有对象在处理时都必须被处置。

【参考方案1】：

尽快打开和关闭。让ADO.Net 连接池负责最大限度地减少实际连接到数据库的开销。只要您使用相同的连接字符串，关闭连接并不会真正关闭它。它只是将其释放回 ADO.Net 连接池。将其保持打开的时间越长（而不是在池中），池可能需要创建更多的实际连接来为数据库请求提供服务。

【参考方案2】：

主要取决于您正在设计什么样的应用程序，但最好尽快关闭它们（但不一定在执行单个查询后立即重新打开，只需五行代码后重新打开 - 重新打开连接也需要时间，而且在高 ping 连接上，这可能会成为难以忍受的用户体验）。

只要您结束需要打开连接的任务（例如从数据库收集数据）并启动另一个任务（例如处理数据）或等待用户输入，请务必关闭连接。请记住，您可以将连接作为参数传递给您可能正在调用的方法，以节省连接池。

【讨论】：

除非您明确编写代码来自己管理连接，否则 ADO.Net 会为您处理这个问题。 “关闭”（或“打开”）连接实际上并没有关闭或打开它。它只是向 ADO.Net 框架连接池服务发送一个请求，该服务（在关闭时）将连接放回池中以供重用，或者（打开）从池中获取另一个打开的 [可用] 连接。池只有在它为空并且有新请求进来时才会创建一个新连接。