我正在使用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;
}
这个查询是否合适？还是数据库连接会比必要的时间更长地保持打开状态？
感谢任何建议。
连接将自动管理。不过，根据评论所述，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 dispose的代码（也使用了Reflector），发现以下代码（FW 3.5）将从DataContext.Dispose中调用：
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实例，例如一个文件写入器，然后自动关闭。
据我所知，其他属性只占用内存，但是通过处理方法，也可以将其释放以进行垃圾回收，但是不能确定实际释放内存的时间。
因此，最后我完全同意casparOne的说法:
一般来说，共享数据访问资源是不好的做法。
您应该创建用于访问数据库的资源，在完成操作后对其进行处理。
使用 Linq-To-SQL 时，通常不需要特别关注上下文对象（例如您示例中的 db）中包含的连接的打开和关闭。唯一需要这样做的情况是，如果您通过上下文对象发送直接 SQL 调用而不是使用 Linq，则必须这样做。
使用 L2S 时，通常希望尽快创建上下文对象、执行工作单元，然后处理对象。您的代码示例看起来很好。
我认为使用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;
}
}
数据库连接将在您的db对象不再存在（已释放）或明确关闭后立即关闭。在您的示例中，它将被垃圾回收（早晚）。
provider成员，并将services、tables和loadOptions成员设置为null。在SqlProvider中的Dispose方法（由DataContext Dispose方法调用）会关闭connection成员，并将其他一些成员设置为null。因此，我不会说它什么都没做。 - Robert Harvey