在Windows窗体应用程序中，当窗体启动时，它会从数据库加载数据。它首先转到持久性数据层并创建新的DBContext。
public DataEntities DBContext = new DataEntities();
之后加载数据。
我在表单关闭事件上配置DBContext。原因是我使用DBContext的Local属性来查询数据。因此它在加载后查询内存数据而不是良好（快速）的数据库。 另一件事是只有启动程序的用户才能访问自己的数据（而不是其他用户的数据）。所以任何人都没有机会修改他的数据（只有他的副手）。
因此，在表单关闭之前不会释放DBContext。
注1：这是输入数据的表格。它不是主要形式。在主表格上，我将立即处理它，因为主表格仅用于查看数据。
注2：应用程序将在本地网络中使用，用户数量大约为40。
注3：我使用实体框架6.1.3
在启动时加载数据后，在sql profiler中我注意到sql命令被调用：
exec sp_reset_connection
我的问题是： 我可以使用这种方法并在表单关闭时（在表单关闭事件上）处理DBContext吗？
答案 0 :(得分：1)
当你的DbContext有很长的实时时间时，这里有一些考虑因素（连接的实体）：
SQL Server中的每个检索到的实体都将加载到第一级缓存（RAM USAGE）的内存中。
如果数据从其他DbContext更改，您可能会遇到一些并发问题。
如果您的SQL Server TRANSACTION ISOLATION LEVEL是READ UNCOMMITTED，那么您可能会收到脏读。
如果您在DbContext（Thousands）中加载了很多实体，那么应用程序通常会变慢，当您尝试更改实体时可能会遇到性能问题，因为EF必须跟踪它们所有
答案 1 :(得分：1)
不确定。这称为连接方案，即上下文与数据库保持“连接”（注意引号），并保存从数据库中获取的相同实体。
在像Windows窗体应用程序这样的富客户端应用程序中，这是相对短暂的编辑对话框窗口的常见模式。而这正是你在这里所做的。
上下文实际上并不保持与数据库的开放连接。它在每次数据库交互后关闭连接，因此Sql Profiler记录。
有一点需要考虑。即使用户同时编辑相同数据的可能性很小，也可能建议引入optimistic concurrency control。 EF使这相对容易。