实体框架和连接池

1. 连接池的处理方式与任何其他方法相同ADO.NET应用程序。实体连接仍然使用传统的数据库连接和传统的连接字符串。我相信如果不想使用连接字符串,可以关闭连接池。(阅读更多关于 SQL Server Connection Pooling (ADO.NET) )
2. 永远不要使用全局上下文。ObjectContext在内部实现了几个模式,包括身份映射和工作单元。使用全局上下文的影响因应用程序类型而异。

如果您想知道WPF/WinForm应用程序的单对象上下文有什么影响,请检查 article

身份映射模式 . 您可以强制对象上下文重新加载实体,但它将重新加载单个共享实例。

SaveChanges 关于上下文。您可以在多个实体中进行更改并一次存储它们。这叫做 . 您不能有选择地说出要保存哪个已修改的附加实体。

结合这两种模式,您将看到一些有趣的效果。整个应用程序只有一个实体实例。对实体的任何更改都会影响整个应用程序,即使更改尚未持久化(提交)。在大多数情况下,这不是你想要的。假设您在WPF应用程序中有一个编辑表单。您正在处理实体,并决定取消复杂的编辑(更改值、添加相关实体、删除其他相关实体等)。但实体已在共享上下文中修改。你会怎么做?提示:我不知道上有任何取消更改或取消更改 ObjectContext .

我想我们不必讨论服务器场景。简单地在多个HTTP请求或Web服务调用之间共享单个实体会使您的应用程序毫无用处。任何请求都可以触发 并保存另一个请求的部分数据,因为您在所有请求之间共享单个工作单元。这还将有另一个问题-上下文和对上下文中的实体或上下文使用的数据库连接的任何操作都不是线程安全的。

据丹尼尔·西蒙斯说:

在中创建新的ObjectContext实例 每个服务的Using语句 在方法返回之前。

http://msdn.microsoft.com/en-us/magazine/ee335715.aspx

我相信这个建议可以扩展到HTTP请求,所以对于ASP.NET. 有状态的胖客户端应用程序(如WPF应用程序)可能是“共享”上下文的唯一情况。

https://msdn.microsoft.com/en-us/data/hh949853#9

9.3每个请求的上下文

实体框架上下文被用作短期实例,以提供最佳的性能体验 . 上下文被认为是短暂的和被丢弃的,因此被实现为非常轻量级的,并且尽可能地重用元数据。在web场景中,重要的是要记住这一点,并且上下文不能超过单个请求的持续时间。类似地,在非web场景中,应该根据您对实体框架中不同缓存级别的理解来丢弃上下文。 一般来说,应该避免在应用程序的整个生命周期中使用上下文实例,以及每个线程的上下文和静态上下文。

下面的代码帮助我的对象用新的数据库值刷新。Entry(object).Reload()命令强制对象调用数据库值

GM_MEMBERS member = DatabaseObjectContext.GM_MEMBERS.FirstOrDefault(p => p.Username == username && p.ApplicationName == this.ApplicationName);
DatabaseObjectContext.Entry(member).Reload();