我应该什么时候处理数据上下文 [英] When should I dispose of a data context

问题描述

我目前正在为应用程序编写数据访问层.访问层广泛使用 linq 类来返回数据.目前为了将数据反映回数据库，我添加了一个私有数据上下文成员和一个公共保存方法.代码如下所示:

I'm currently writing a data access layer for an application. The access layer makes extensive use of linq classes to return data. Currently in order to reflect data back to the database I've added a private data context member and a public save method. The code looks something like this:

private DataContext myDb;
public static MyClass GetMyClassById(int id)
{
    DataContext db = new DataContext();
    MyClass result = (from item in db.MyClasss
                      where item.id == id
                      select item).Single();
    result.myDb = db;
    return result;
}

public void Save()
{
    db.SubmitChanges();
}

这过于简单化了，但它给出了总体思路.有没有更好的方法来处理这种模式?每次我想访问数据库时，我都应该实例化一个新的数据上下文吗?

That's a gross over simplification but it gives the general idea. Is there a better way to handle that sort of pattern? Should I be instantiating a new data context every time i want to visit the db?

推荐答案

其实没有太大关系.不久前，我向 LINQ to SQL 团队的 Matt Warren 询问了这个问题，答案如下:

It actually doesn't matter too much. I asked Matt Warren from the LINQ to SQL team about this a while ago, and here's the reply:

我们实施的原因有几个IDisposable:

There are a few reasons we implemented IDisposable:

如果应用逻辑需要保持到一个实体之后预计将使用 DataContext 或有效，您可以通过以下方式执行该合同调用处置.延迟加载器该实体仍将引用DataContext 并将尝试使用它如果任何代码尝试导航延迟属性.这些尝试将失败.Dispose 也强制DataContext 转储其缓存实体化实体，以便单个缓存实体不会意外保持所有实体的存活通过那个 DataContext，这将否则会导致看起来像内存泄漏.

If application logic needs to hold onto an entity beyond when the DataContext is expected to be used or valid you can enforce that contract by calling Dispose. Deferred loaders in that entity will still be referencing the DataContext and will try to use it if any code attempts to navigate the deferred properties. These attempts will fail. Dispose also forces the DataContext to dump its cache of materialized entities so that a single cached entity will not accidentally keep alive all entities materialized through that DataContext, which would otherwise cause what appears to be a memory leak.

自动关闭的逻辑DataContext 连接可以是被骗离开连接打开.DataContext 依赖于枚举所有的应用程序代码查询结果结果集的结尾触发连接关闭.如果应用程序使用 IEnumerable 的MoveNext 方法而不是 foreach在 C# 或 VB 中声明，您可以退出枚举过早.如果你的应用程序遇到问题连接没有关闭和你怀疑自动关闭行为不工作，你可以使用 Dispose模式作为一种解决方法.

The logic that automatically closes the DataContext connection can be tricked into leaving the connection open. The DataContext relies on the application code enumerating all results of a query since getting to the end of a resultset triggers the connection to close. If the application uses IEnumerable's MoveNext method instead of a foreach statement in C# or VB, you can exit the enumeration prematurely. If your application experiences problems with connections not closing and you suspect the automatic closing behavior is not working you can use the Dispose pattern as a work around.

但基本上，在大多数情况下，您真的不需要处理它们 - 这是设计使然.无论如何，我个人更喜欢这样做，因为遵循处理实现 IDisposable 的所有内容"的规则比记住大量异常更容易 - 但是如果您这样做<，则不太可能泄漏资源 忘记处理它.

But basically you don't really need to dispose of them in most cases - and that's by design. I personally prefer to do so anyway, as it's easier to follow the rule of "dispose of everything which implements IDisposable" than to remember a load of exceptions to it - but you're unlikely to leak a resource if you do forget to dispose of it.

这篇关于我应该什么时候处理数据上下文的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！