EF6学习笔记十四：上下文管理
ObjectContext 转 DbContext
View Code现在来说我理解的一些上下文管理的东西。
上下文生命周期管理
上下文我知道，不过也是后来才知道。当一个东西，不给出上下文你是不能很好的理解他的，因为没有约束，范围太大，对于不同的环境有不同的理解。和说话一样，对于一句话你还要给出这句话的语境，别人才能真正知道。
当我说出一句“真香”，你知道我说的是真的香还是真香定律？这和泛型约束一样，我们对类型添加的那些约束也可以看做是这个类型的上下文。
我最开始弄EF，同样的是派生一个上下文，但是那时我给上下文取的变量名是“db”，因为我就认为它是一个虚拟的数据库。但是觉得不准确，而且直到我无意中看到上下文中有个属性叫Database……
如果上下文就是数据库，那么它怎么还要有一个Database属性呢？肯定不是这样的，Database应该看做是EF这个语境中的一句话，这个大语境中还有配置、追踪……这些内容，所以要理解整个语境才能理解一句话。弄懂上下文和他里面database的关系。
生命周期，什么意思，按照字面意思来说，一个人从出生到死亡的过程就是这个人的生命周期，一个手机生产到使用报废的过程，再怎么玄之又玄的解释肯定不能怀疑不能动摇，它就是一个出生到死亡的过程。
我这说了好像等于没说啊，其实，我想要对自己强调一遍。根本性的东西不能动摇。既然它叫了这个名字，那么如果实际情况不是这样，只能说明是它的问题不是我的问题。
因为概念性的东西老是听别人说来说去，一个这样说，另一个那样说，如果你不去继续研究，他对你就是一个模糊的、说不出来的东西，而且会怀疑他的命名。
上下文生命周期管理，说的就是……上下文生命周期管理
上下文的生命周期开始于初始化，结束于被垃圾回收器回收并释放。释放？你释放就是了，你不是内存托管吗？
原来，要是你不使用using来包括上下文，就要自己手动释放资源。
可是你不是内存托管吗？我自己创建一个Studen类，也从来不用去手动释放啊
在以前写ado的时候我记得要创建数据库连接，用try/catch包裹起来，最后在finally中调用close方法关闭连接。
后来我知道了托管代码和非托管代码这一个东西。我的理解就是只要你不写指针不自己操作内存，那么就是写的托管代码。
所以我认为是不是有些东西不能托管，百度了一下果然：
“系统的资源包括托管资源和非托管资源。例如文件流，数据库的连接，系统的窗口句柄，打印机资源等等这些是非托管资源。” upload/201901211650343668.gif" alt="复制代码" style="margin: 0px; padding: 0px; max-width: 900px; height: auto; border: none !important;" />
var res = ctx.Products.Where(x => x.Order != null).ToList(); Console.WriteLine(JsonConvert.SerializeObject(res, set));
SQL的执行情况是这样
可以看到EF每执行一次SQL，就会打开/关闭一次数据库连接
那就说明他自己有关闭数据库连接的能力啊，并不是我的上下文对象销毁了，数据库连接才关闭。
但是总的来说上下文你不使用using来包裹，就需要手动释放资源，肯定是用到了哪些非托管资源。
如何更干净地使用上下文
我一开始使用EF，实例化上下文和普通对象是一样的写法，因为我不知道除非using包裹就要手动释放资源。
using几年前我就见到了，一直没有去弄过，不知道怎么回事，在写ado的时候我用的try/catch也看到有人写using
原来这个using可以看做就是try/catch的语法糖，using经过反编译后的本质是创建try/finally块，并最终在finally中调用Dispose方法释放。
书中这样说："在使用上下文时，始终要谨记一个准则：一个请求对应一个上下文。在项目中上下文全局唯一，这种方式显然不可取，在多线程web应用程序中性能极低，尤其对并发操作。"
我们来看三种上下文使用方式
Using Pattern 使用using，这种方式的缺点，控制器中的方法可能用到上下文的情况非常多，这样就会到处充斥这些using
View CodeDisPose Pattern 上下文和控制器一同创建和销毁
View CodeDependency Injection 依赖注入的方式是最被开发者推荐的模式
View Code现在上下文就不是由控制器来创建和销毁了，而且被注入进来的，控制器只管使用就行了。我对依赖注入没有什么认识，一直没有去弄。注入明白，依赖呢？难道是这个被注入的对象和控制器的构造函数绑定在一起了，二者缺一不可，形成了依赖关系？
行吧，书中讲到了生命周期追溯,
