更高效的数据库访问

我是数据库和 linq 的新手，所以我的问题可能被认为是微不足道的。我目前在每个类中启动所有数据库请求：

 DataClassesDataContext db = new DataClassesDataContext()

然后，我继续在该方法中发出我需要的任何 linq 请求，并继续执行主要应用程序逻辑。

现在，两个有趣的问题：

1）我相信我见过人们将数据库使用包装在“使用”中。例如：

using (DataClassesDataContext db = new DataClassesDataContext())
{
    ...
}

如果这是正确的，那么这是否意味着我的类不能再使用成员“db”变量，而是需要在每个函数调用中发出这些数据库请求？另外，如果我在通话中不使用“using”，到底会发生什么？

2) 在启用 SQL Profiler 的情况下运行我的应用程序，我看到许多连接打开和关闭。这是否意味着每个 DataClassesDataContext 调用都会建立一个单独的连接？这似乎效率低下，那么实际上使 DataClassesDataContext 对象在每个正在使用的类中成为静态对象的正确方法是吗？

一般来说，您应该使用一个DataContext每个数据库对话。只有您才能准确决定对话是什么，但通常它是一个完整的请求（例如，获取用户的愿望清单，或获取用户的已关闭订单），您可能将其视为“工作单元”。

通常发生的情况是这样的：

WishList wishlist;
using(var context = new DataContext(connectionString)) {
    var service = new UserWishListService(context);
    wishlist = service.GetUserWishList();
}

另外，如果我不使用到底会发生什么using在通话中？

The DataContext不会被妥善处理（除非你用try-catch-finally，但通常你应该只使用using).

这是否意味着每个DataClassesDataContext呼叫建立单独的连接？

不完全的。您的应用程序将受益于 SQL Server ADO.NET 提供程序的内置功能连接池 http://en.wikipedia.org/wiki/Connection_pool。不用担心这个，让提供商为您管理。

这似乎效率低下，因此实际制作的正确方法是DataClassesDataContext对象astatic在每个正在使用的类中？

绝对不。DataContexts 不是线程安全的（事实上，它们是线程不安全的），这上面写满了“有龙”。此外，即使是单线程上下文，static DataContext是一个糟糕的选择，因为DataContext维护从数据库中提取的所有实体的缓存（用于对象跟踪目的）。随着时间的推移，内存消耗将变得巨大。