我的数据库连接关闭了吗？ （Linq 到 Sql）

Question

我正在使用 Linq to SQL 并阅读了有关尽快关闭数据库连接的博客文章。作为示例，他们展示了一个变量被转换为列表（使用 .ToList()），而不是实际返回 Linq 查询。我有以下代码：

 public static bool HasPassword(string userId)
 {

    ProjDataContext db = new ProjDataContext();

    bool hasPassword = (from p in db.tblSpecUser
                                    where p.UserID == userId
                                    select p.HasPassword).FirstOrDefault();


    return hasPassword;
 }

该查询可以吗？或者数据库连接保持打开状态的时间是否会超过必要的时间？

感谢您的任何建议

Answer 1

连接将被自动管理。然而，还有（或者至少可以像评论所建议的那样）与 DataContext 相关的其他资源。直到 DataContext 被垃圾收集器销毁后，这些资源才会被释放。因此，通常最好确保当您不再需要 DataContext 时调用 dispose。

using (ProjDataContext db = new ProjDataContext()) {
    bool hasPassword = (from p in db.tblSpecUser
                                    where p.UserID == userId
                                    select p.HasPassword).FirstOrDefault();


    return hasPassword;
}

这里确保在 using 块退出时调用 db.Dispose() ，从而显式关闭连接。

编辑：在讨论之后，我查看了自己的 DataContext 处置（也使用 Reflector）并发现了从 DataContext.Dispose 调用的以下代码（FW 3.5）

protected virtual void Dispose(bool disposing)
{
    if (disposing)
    {
        if (this.provider != null)
        {
            this.provider.Dispose();
            this.provider = null;
        }
        this.services = null;
        this.tables = null;
        this.loadOptions = null;
    }
}

： 是被释放的资源：

• 可能持有DbConnection、日志(TextWriter)和<代码>DbTransaction。
• CommonDataServices。
• 表字典。
• LoadOptions。

提供者可能持有需要处置的资源（DbConnection 和 DbTransaction）。此外，日志的 TextWriter 可能必须被释放，具体取决于用户分配给 DataContext 日志记录的 TextWriter 实例机制，例如 FileWriter 然后自动关闭。

据我了解，其他属性仅保留内存（无需过多查看细节），但这也可以通过 dispose 方法用于垃圾回收，但是，内存实际释放的时间并不确定。

所以，最后我完全同意casparOne的说法：

一般来说，像这样共享数据访问资源是一个坏主意。

您应该创建资源来访问数据库、执行操作，然后在完成后处置它们。

Answer 2

从实现的角度来看，不，你没有什么可担心的。但是，这不是由于查询，而是由于 DataContext 本身。

DataContext 类实现 IDisposable 接口，因此您应该调用每当您使用完 DataContext 实现后，就对其进行处置。

现在，众所周知的事实是，在 DataContext 实例上调用 Dispose 不会执行任何操作，因此不是 技术上需要。

不幸的是，这也是非常糟糕的做法。您应该始终根据合同而不是实现进行编码。因为 DataContext 实现了 IDisposable，所以您应该关闭它，即使您知道它什么都不做，因为这在未来的实现中绝对可能会发生变化。

另外，如果您切换到另一个 LINQ 提供程序（例如 LINQ-to-Entities），那么您必须在完成后调用 Dispose，因为数据库连接的生命周期在 ObjectContext 实例（也实现 IDisposable）非常不同，并且调用 Dispose对这些数据库连接有影响。

话虽如此，你还有一个更大的担忧。如果您共享一个 DataContext，则可能会面临跟踪过多对象的风险。除非您设置了 ObjectTrackingEnabled 属性 设置为 false 时，DataContext 正在跟踪通过它选择的每个对象。如果您在应用程序的生命周期内没有执行任何更新操作（或者即使您执行了更新操作），则专用于共享 DataContext 上的对象跟踪的资源数量可能会变得相当大。

使用其他数据库技术开发的规则（例如 System.Data.SqlClient 命名空间）仍然适用。

一般来说，像这样共享数据访问资源是一个坏主意。

您应该创建资源来访问数据库、执行操作，然后在完成后处置它们。

Answer 3

使用 Linq-To-SQL，您通常不需要关心具体打开和关闭作为上下文对象（示例中的 db）一部分的连接。大约唯一需要专门执行此操作的情况是，如果您通过上下文对象发送直接 SQL 调用，而不是使用 Linq。

使用 L2S，您通常希望创建上下文对象，执行工作单元，然后尽快处理该对象。你的代码示例对我来说看起来不错。

Answer 4

我认为使用 using 语句是一个很好的做法。但我认为你的询问没有什么不好。

public static bool HasPassword(string userId)
 {

    using(var db = new ProjDataContext())
    {

       bool hasPassword = (from p in db.tblSpecUser
                                    where p.UserID == userId
                                    select p.HasPassword).FirstOrDefault();


        return hasPassword;
    }
}

Answer 5

在您的数据库对象不再存在（处置）或显式关闭后，数据库连接将立即关闭。
在您的示例中，它将（迟早）被垃圾收集。