实体框架和连接池 [英] Entity Framework and Connection Pooling

问题描述

我最近开始使用Entity Framework 4.0中在我的.NET 4.0的应用程序，并很好奇的几件事情有关池。

1. 连接池，因为我知道由ADO.NET数据提供商管理的，在我的情况是MS SQL服务器。这是否当你实例化一个新的实体环境中应用（的ObjectContext ），即无参数新MyDatabaseModelEntities（）？

2. 有哪些优点和一个缺点）建立一个全球性的实体范围内的应用程序（即一个静态实例）或b）创建和暴露的实体上下文每一个给定的操作/方法，用使用块。

3. 任何其他建议，最佳实践，或者某些情况下常见的办法，我应该知道的？

解决方案

1. 连接池是在任何其他ADO.NET应用程序处理。实体连接仍然采用传统的连接字符串传统的数据库连接。我相信你可以在连接字符串中关闭连接系统，池，如果你不想使用它。 （阅读更多有关 SQL Server的连接池（ADO.NET））
2. 永远不要使用全局范围内。 ObjectContext的内部实现多种模式，包括标识映射和工作单位。利用全球范围内的影响是每个应用程序的类型不同。
3. 对于Web应用程序使用的每个请求的单一环境。对于Web服务使用每次通话单独的环境。在的WinForms或WPF应用程序中使用单个的上下文，每个表单或每presenter。可能有一些特殊的要求，将不允许使用这种方法，但在大多数情况下，这是不够的。

如果你想知道什么样的影响一直为WPF / WinForm应用程序单个对象的上下文检查这文章。它是关于NHibernate的会议，但这个想法是一样的。

编辑：

当你使用EF默认情况下它加载每个实体每个上下文只有一次。第一个查询创建实体instace它内部存储。任何后续的查询需要使用相同的密钥将返回该存储实例的实体。如果在数据存储的值更改您仍然收到与初始查询值的实体。这就是所谓的身份地图模式。您可以强制对象上下文来重新加载实体，但它会重新加载一个共享实例。

对实体所做的任何更改都不会持续，直到调用的SaveChanges 上下文。你可以改变多个实体和存储一次他们。这就是所谓的单元的工作模式。你可以有选择地说哪个修改连接实体要保存。

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

我想我们没有讨论服务器方案。简单地共享多个HTTP请求或Web服务调用之间的单一实体，使您的应用程序形同虚设。任何请求都可以只触发的SaveChanges ，并从另一个请求保存的部分数据，因为您共享单个的工作单位之间的所有的人。这也将有另一个问题 - 背景和任何操作，在使用的上下文中的上下文或数据库连接实体不是线程安全的。

即使是一个只读的应用程序在全球范围内是不是一个好的选择，因为你可能每次都希望新的数据你查询应用程序。

I've recently started to use the Entity Framework 4.0 in my .NET 4.0 application and am curious about a few things relating to pooling.

1. Connection pooling as I know is managed by the ADO.NET data provider, in my case that of MS SQL server. Does this apply when you instantiate a new entities context (ObjectContext), i.e. the parameterless new MyDatabaseModelEntities()?

2. What are the advantages and disadvantages of a) creating a global entities context for the application (i.e. one static instance) or b) creating and exposing an entities context for each given operation/method, with a using block.

3. Any other recommendations, best practices, or common approaches for certain scenarios that I should know about?

解决方案

1. Connection pooling is handled as in any other ADO.NET application. Entity connection still uses traditional database connection with traditional connection string. I believe you can turn off connnection pooling in connection string if you don't want to use it. (read more about SQL Server Connection Pooling (ADO.NET))
2. Never ever use global context. ObjectContext internally implements several patterns including Identity Map and Unit of Work. Impact of using global context is different per application type.
3. For web applications use single context per request. For web services use single context per call. In WinForms or WPF application use single context per form or per presenter. There can be some special requirements which will not allow to use this approach but in most situation this is enough.

If you want to know what impact has single object context for WPF / WinForm application check this article. It is about NHibernate Session but the idea is same.

Edit:

When you use EF it by default loads each entity only once per context. The first query creates entity instace and stores it internally. Any subsequent query which requires entity with the same key returns this stored instance. If values in the data store changed you still receive the entity with values from the initial query. This is called Identity map pattern. You can force the object context to reload the entity but it will reload a single shared instance.

Any changes made to the entity are not persisted until you call SaveChanges on the context. You can do changes in multiple entities and store them at once. This is called Unit of Work pattern. You can't selectively say which modified attached entity you want to save.

Combine these two patterns and you will see some interesting effects. You have only one instance of entity for the whole application. Any changes to the entity affect the whole application even if changes are not yet persisted (commited). In the most times this is not what you want. Suppose that you have an edit form in WPF application. You are working with the entity and you decice to cancel complex editation (changing values, adding related entities, removing other related entities, etc.). But the entity is already modified in shared context. What will you do? Hint: I don't know about any CancelChanges or UndoChanges on ObjectContext.

I think we don't have to discuss server scenario. Simply sharing single entity among multiple HTTP requests or Web service calls makes your application useless. Any request can just trigger SaveChanges and save partial data from another request because you are sharing single unit of work among all of them. This will also have another problem - context and any manipulation with entities in the context or a database connection used by the context is not thread safe.

Even for a readonly application a global context is not a good choice because you probably want fresh data each time you query the application.

这篇关于实体框架和连接池的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！