1.DbContext怎么在Asp.mvc中使用?

  public class Repository
{
//实例化EF容器:有弊端。一个线程里可能会创建多个DbContext
//DbContext db = new DbContext(); //改造:保证一个请求线程中只有一份EF容器(你要明白:一个url请求到服务器,IIS就开一个线程去处理)
protected DbContext GetDbContext
{
get
{
//向线程缓存中查询,如果返回的是null,则创建,同时存入到这个线程缓存中
//注意的是线程缓存CallContext,而不是我们熟悉的HttpRuntime.cache。意味着这个DbContext对象在这个线程内能被其他方法共享。
object efDbContext = CallContext.GetData("DbContext");
if (efDbContext == null)
{
efDbContext = new DbContext();
//存入到这个线程缓存中
CallContext.SetData("DbContext", efDbContext);
}
return efDbContext as DbContext;
}
}
}

  这么定义之后,所有需要用到DbContext对象的地方,都调这个方法。

2. 不要随便using或Dispose DbContext会导致延迟加载的不可用,还会有一些其他错误 如IQueryable<T> 下面的方法(.First() /.Count())也不能用。

情况一:

  a写法结果正确

PhoneBookEntities phoneBookEntities = new PhoneBookEntities();
var ci = phoneBookEntities.ContactInfo.FirstOrDefault();//这里并没有拿到ci对象里面的GroupInfo属性。
if (ci != null) MessageBox.Show(ci.GroupInfo.GroupName);//是延迟加载,访问 ci.GroupInfo.GroupName 才会去数据库查数据

  b写法报错

ContactInfo ci = null;
using (PhoneBookEntities phoneBookEntities = new PhoneBookEntities())
{
ci = phoneBookEntities.ContactInfo.FirstOrDefault();
} if (ci != null) MessageBox.Show(ci.GroupInfo.GroupName);
//报错:此ObjectContext实例已释放,不可再用于需要连接的操作。意味着延迟加载不可用。

情况二:

  a写法报错

IQueryable<ContactInfo> ci = null;
using (PhoneBookEntities phoneBookEntities = new PhoneBookEntities())
{
ci = phoneBookEntities.ContactInfo.Where(c => true);
} if (ci != null) MessageBox.Show(ci.Count().ToString());//报错:提示DbContext已经释放。

  b写法正确

IQueryable<ContactInfo> ci = null;
using (PhoneBookEntities phoneBookEntities = new PhoneBookEntities())
{
ci = phoneBookEntities.ContactInfo.Where(c => true);
if (ci != null) MessageBox.Show(ci.Count().ToString());//可以返回正确结果。
}

  

3.为什么你要using 或dispose掉DbContext ?

是担心数据库连接没有释放?还是担心DbContext占用过多资源呢?
首先担心数据库连接没有释放肯定是多余的,因为DbContext在SaveChanges完成后会释放掉打开的数据库连接。
可以反编译一下SaveChages的源码。
担心DbContext占用过多资源也是多余的,有GC回收。

结论,You can call Dispose, but in most common scenarios you don’t need to.

更详细的可以看这个英文博客的文章,其中有 Diego Vega (the Senior SDE Lead on EF) 的回信:

Hello Jon,

The default behavior of DbContext is that the underlying connection is automatically opened any time is needed and closed when it is no longer needed. E.g. when you execute a query and iterate over query results using “foreach”, the call to IEnumerable<T>.GetEnumerator() will cause the connection to be opened, and when later there are no more results available, “foreach” will take care of calling Dispose on the enumerator, which will close the connection. In a similar way, a call to DbContext.SaveChanges() will open the connection before sending changes to the database and will close it before returning.

Given this default behavior, in many real-world cases it is harmless to leave the context without disposing it and just rely on garbage collection.

That said, there are two main reason our sample code tends to always use “using” or dispose the context in some other way:

1. The default automatic open/close behavior is relatively easy to override: you can assume control of when the connection is opened and closed by manually opening the connection. Once you start doing this in some part of your code, then forgetting to dipose the context becomes harmful, because you might be leaking open connections.

2. DbContext implements IDiposable following the recommended pattern, which includes exposing a virtual protected Dispose method that derived types can override if for example the need to aggregate other unmanaged resources into the lifetime of the context.

By the way, with DbContext the pattern to open the connection manually and override the automatic open/close behavior is a bit awkward:

((IObjectContextAdapter)dbContext).ObjectContext.Connection.Open()

But we have a bug to make this easier as it used to be with ObjectContext before, e.g.:

dbContext.Database.Connection.Open()

Hope this helps,

Diego

附上参考博客:http://www.cnblogs.com/mecity/archive/2011/07/17/2108508.html

EntityFramework中的DbContext使用疑点说明的更多相关文章

  1. EntityFramework 中支持 BulkInsert 扩展

    本文为 Dennis Gao 原创技术文章,发表于博客园博客,未经作者本人允许禁止任何形式的转载. 前言 很显然,你应该不至于使用 EntityFramework 直接插入 10W 数据到数据库中,那 ...

  2. EntityFramework中的线程安全,又是Dictionary

    继上次记一次w3wp占用CPU过高的解决过程(Dictionary和线程安全)后又再次与Dictionary博弈,这一次是在EntityFramework中的Dictionary. 从一个异常说起 这 ...

  3. EntityFramework中支持BulkInsert扩展(转载)

    前言 很显然,你应该不至于使用 EntityFramework 直接插入 10W 数据到数据库中,那可能得用上个几分钟.EntityFramework 最被人诟病的地方就是它的性能,处理大量数据时的效 ...

  4. EntityFramework中支持BulkInsert扩展

    EntityFramework中支持BulkInsert扩展 本文为 Dennis Gao 原创技术文章,发表于博客园博客,未经作者本人允许禁止任何形式的转载. 前言 很显然,你应该不至于使用 Ent ...

  5. entityFramework 中decimal精度缺失问题

    在entityFramework中,decimal精度默认为2位数,当要设置的精度大于2位并且数据库中设置的decimal精度大于2位时,则将数据保存在数据库中后两位的小数内容将强制为00 解决方案: ...

  6. EntityFramework中几种操作小结

    目前项目中使用到的EntityFramework中几种操作小结,先标记下.没有详细介绍,后续有空的话再补充一些并完善一下. 列中加入RowVersion时间戳 public class Product ...

  7. 设置EntityFramework中decimal类型数据精度问题(EF默认将只会保留到2为精度)

    原文:设置EntityFramework中decimal类型数据精度 EF中默认的decimal数据精度为两位数,当我们数据库设置的精度大于2时,EF将只会保留到2为精度. e.g. .19990将会 ...

  8. 工作总结 EntityFramework中出现DateTime2异常的完美解决办法

    EntityFramework中出现DateTime2异常的完美解决办法   今天在使用entityframework往数据库插入数据的时候,突然出现了一个数据类型转换异常的问题: System.Da ...

  9. [转]EntityFramework中常用的数据修改方式

    本文转自:http://blog.csdn.net/itmaxin/article/details/47662151 上一篇文章里提到了 EntityFramework中常用的数据删除方式,那么修改对 ...

随机推荐

  1. 简单搭建 nuget 内部服务器

    搭建 nuget 内部服务器,最好的方式是使用 ProGet,参考博文<用 ProGet 搭建内部的 NuGet 服务器>,好处非常多,但需要使用 SQL Server 数据库,如果不想使 ...

  2. $ORACLE_HOME变量值末尾多“/”惹的祸

    之前一直误以为$ORACLE_HOME变量的路径中末尾多写一个"/"不会有影响. 今天做实验时碰到一个情景,发现并不是这样. 环境:OEL 5.7 + Oracle 10.2.0. ...

  3. SAP CRM 性能小技巧

    导言 本页面打算收集SAP CRM实施中可以用于避免性能问题的注意事项,重要的事项会由图标标识. 如果你有其他的技巧想要说出来,别犹豫! 性能注意事项 通用 缓存读取类访问,特别是在性能关键的地方,比 ...

  4. Linux服务器安全配置

    众所周知,网络安全是一个非常重要的课题,而服务器是网络安全中最关键的环节.Linux被认为是一个比较安全的Internet服务器,作为一种开放源代码操作系统,一旦Linux系统中发现有安全漏洞,Int ...

  5. 学习笔记:URL Protocol在浏览器中打开本地应用程序

    看到阿里的网站上可以通过点击卖家的旺旺图标从而调用本地的阿里旺旺程序,而且还可以传递当前浏览者需要咨询的商品.这是怎么实现的呢?是通过URLProtocol来完成. 原理还没有太清楚,即在系统里注册一 ...

  6. JNI 备注

    本文记录一个基础的JNI例子及过程中遇到的问题解决. 1.定义一个JAVA类如下: package jnidemo01; public class JniHello { public native v ...

  7. Java 开发主流 IDE 环境体验

    前言 本来应该继续从 Oracle 官网搬砖的,但是随着示例代码越来越复杂,涉及的类库越来越多,使用 Vim 写 Java 代码就很力不从心了,是时候上 IDE 了.我最熟悉的 IDE 环境是 Ecl ...

  8. CSharpGL - Object Oriented OpenGL in C#

    Object Oriented OpenGL in C#

  9. struts debug 标签

    < s:debug> 引起下面的错误 org.apache.jasper.JasperException: Caught an exception while getting the pr ...

  10. Docker之Compose服务编排

    Compose是Docker的服务编排工具,主要用来构建基于Docker的复杂应用,Compose 通过一个配置文件来管理多个Docker容器,非常适合组合使用多个容器进行开发的场景. 说明:Comp ...