相关疑难解决方法(0)

我不知道是否有更好的方法来使用它,DbContext因为在使用WCF时不建议将其设置为静态.所以我们每次想要访问数据库时都会创建它.

了解使用实体框架的所有优点,有些变得无用,因为我们DbContext每次都在重新创建; 因为要考虑创建大实体模型的过程,所以可能会导致更多开销.

你有什么意见？

管理EntityContext生命周期有很多问题,

例如,在LINQ to Entities中实例化上下文

我得出的结论是,实体上下文应该被视为一个工作单元,因此不能重复使用.大.

但是在进行一些加速我的数据库访问的研究时,我遇到了这篇博文...

改善实体框架性能

该帖子称,EF文件表现不佳相对于其他框架往往是由于EntityConnection对象被每一个新的时间创建的EntityContext需要的对象.

为了测试这一点,我在Global.asax.cs Application_Start()中手动创建了一个静态EntityConnection .

然后我使用语句将我的所有上下文转换为

using( MyObjContext currContext = new MyObjeContext(globalStaticEFConnection)
{
   ....
}

到目前为止,到目前为止,这似乎已经加快了一点点没有任何错误.

但这样安全吗？

使用应用程序范围的静态EntityConnection是否会引入竞争条件？

最好的问候,凯文

我有几个基于System.Entity.Data.DbContext的类.它们在Web应用程序的不同端部被多次使用请求 - 实例化它们是否昂贵？

我在HttpContext.Current.Items中缓存了它们的副本,因为每个请求都有几个副本它们感觉不对,但我现在发现它不会自动从HttpContext处理掉.请求.在我开始编写代码来处理它之前(在Application_EndRequest中),我认为我已经重新考虑了这种情况,因为如果我应该在需要它们的地方实例化它们并在那里处理它们,那么实际上没有必要缓存它们.

互联网上已经提出了与此类似的问题,但我似乎无法找到一个完全回答我的问题的问题.对不起,如果我正在重复某人.

更新

我发现在这篇博客文章中处理上下文可能并不重要,但我仍然有兴趣听到它们首先实例化是否昂贵.基本上,幕后有很多EF魔法,我想避免经常这么做吗？