实体框架和连接池

1. 连接池的处理方式与任何其他ADO.NET应用程序一样。实体连接仍使用带有传统连接字符串的传统数据库连接。我相信，如果您不想使用连接字符串，则可以关闭连接池。（了解有关SQL Server连接池（ADO.NET）的更多信息）
2. 永远不要使用全局上下文。ObjectContext在内部实现了几种模式，包括身份映射和工作单元。每种应用程序类型使用全局上下文的影响是不同的。
3. 对于Web应用程序，每个请求使用单个上下文。对于Web服务，每个调用使用单个上下文。在WinForms或WPF应用程序中，每个表单或每个演示者都使用单个上下文。可能会有一些特殊的要求，这些要求不允许使用这种方法，但是在大多数情况下，这就足够了。

如果您想知道对WPF / WinForm应用程序单个对象上下文有什么影响，请查阅本文。它是关于NHibernate Session的，但是想法是相同的。

编辑：

使用EF时，默认情况下，每个上下文仅加载每个实体一次。第一个查询创建实体实例并将其存储在内部。任何随后的需要实体具有相同键的查询都将返回此存储的实例。如果数据存储中的值发生更改，您仍然会收到来自初始查询的带有值的实体。这称为身份映射模式。您可以强制对象上下文重新加载实体，但是它将重新加载单个共享实例。

在调用SaveChanges上下文之前，对实体所做的任何更改都不会保留。您可以在多个实体中进行更改并立即存储它们。这称为工作单元模式。您无法选择性地说出要保存的修改后的附加实体。

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

我认为我们不必讨论服务器方案。在多个HTTP请求或Web服务调用之间简单地共享单个实体会使您的应用程序无用。任何请求都只能触发SaveChanges并保存来自另一个请求的部分数据，因为您要在所有请求之间共享一个工作单元。这也将带来另一个问题-上下文，对上下文中的实体或上下文使用的数据库连接进行的任何操作都不是线程安全的。

即使对于只读应用程序，全局上下文也不是一个好选择，因为每次查询应用程序时您可能都希望有新数据。