管理 EntityConnection 生命周期
关于管理 EntityContext 生命周期存在很多问题，
我得出的结论是，实体上下文应被视为工作单元，因此不应重用。伟大的。
但是，在进行一些加快数据库访问速度的研究时，我遇到了这篇博客文章...
该文章认为，与其他框架相比，EF 的性能较差通常是由于每次创建 EntityConnection 对象所致需要一个新的 EntityContext 对象。
为了测试这一点，我在 Global.asax.cs 中手动创建了一个静态 EntityConnection Application_Start()。
然后，我将所有上下文 using 语句转换为 据
using( MyObjContext currContext = new MyObjeContext(globalStaticEFConnection)
{
....
}
我所知，这似乎加快了速度，没有任何错误。
但这安全吗？
使用应用程序范围的静态EntityConnection是否会引入竞争条件？
此致， 克尔文
There have been many question on managing EntityContext lifetime,
e.g. Instantiating a context in LINQ to Entities
I've come to the conclusion that the entity context should be considered a unit-of-work and therefore not reused. Great.
But while doing some research for speeding up my database access, I ran into this blog post...
Improving Entity Framework Performance
The post argues that EFs poor performance compared to other frameworks is often due to the EntityConnection object being created each time a new EntityContext object is needed.
To test this I manually created a static EntityConnection in Global.asax.cs Application_Start().
I then converted all my context using statements to
using( MyObjContext currContext = new MyObjeContext(globalStaticEFConnection)
{
....
}
This seems to have sped things up a bit without any errors so far as far as I can tell.
But is this safe?
Does using a applicationwide static EntityConnection introduce race conditions?
Best regards,
Kervin
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
EntityConnection 被记录为非线程安全 。我认为您可以将它们集中起来，但是您不能对 Web 应用程序使用单个静态连接，因为会涉及许多线程。
EntityConnection is documented to be not thread-safe. I think you could pool them, but you cannot use a single, static connection for a Web application, as there will be many threads involved.
如果您的 EF 上下文是应用程序范围的，请考虑用户 A 已进行更改（未提交）&用户 B 已提交其更改，所有更改都将提交到数据库，因为用户 A 和 B 都已提交到数据库。 B 使用相同的实例
在我的项目中，我为 EF 上下文创建了每个 WebRequest 实例 - 即。上下文对象从 Web 请求的开始到结束都是静态的。该请求中的所有操作都使用相同的 EF 上下文。这显着加快了我的处理速度，并且没有出现上述问题。
实现此目的的一种方法是使用 DI 容器（我使用 Unity）来管理 EF 上下文的生命周期。 Unity 中并未提供现成的每个 Web 请求生命周期管理器，但有大量文章展示了如何做到这一点。
HTH。
If your EF context is Application-wide, consider that user A has made changes (not committed) & user B has committed his changes, all changes will get committed to the database since both user A & B use the same instance
In my project, I did a per WebRequest intance of the EF context - ie. a context object is static from start through end of a web request & all operations in that request work with the same EF context. This has significantly speeded up my processing without the problem mentioned above.
One way to implement this is to use a DI container (I am using Unity) to manage the lifetime of the EF context. The per web request lifetime manager is not given out of the box in Unity, but there are tons of articles out there which show how this can be done.
HTH.