更高效的数据库访问 [英] More efficient database access

问题描述

我是新来的数据库和LINQ，所以我的问题可能被认为是微不足道的。目前，我开始在每个班级所有我的数据库请求：

I am new to databases and linq, so my problem may be considered trivial. I currently start all my db requests in each class with:

 DataClassesDataContext db = new DataClassesDataContext()

然后我继续做出力所能及的LINQ的要求，我需要在方法中，并与主要的应用逻辑进行。

Then I proceed to make whatever linq request I need within the method and carry on with the main application logic.

现在，两个有趣的疑问：

Now, two interesting queries:

1）我相信我看到有人在包装'使用'分贝的使用。如：

1) I believe I have seen people wrapping db usage within 'using'. Such as:

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

如果这是正确的，那么不就意味着我的类不能用一个成员DB变了，但需要在每个函数调用内进行，而这些数据库的请求？另外，如果我不使用'使用'的叫声中究竟会发生什么？

If this is correct, then doesn't it mean that my class can't use a member 'db' variable anymore, but rather those db requests need to be made within each function call? Also, what exactly would happen if I don't use 'using' within the calls?

2）运行我的应用程序启用了SQL事件探查器，我看到大量的连接口闭。这是否意味着每个DataClassesDataContext调用使一个单独的连接？这似乎效率不高，所以是真正使DataClassesDataContext对象的静态每一类中所使用的正确方法吗？

2) Running my app with SQL Profiler enabled, I see lots of connections opening and closing. Does this means that each DataClassesDataContext call makes a separate connection? It seems inefficient, so is the right way to actually make the DataClassesDataContext object a static within each class being used?

推荐答案

既然你添加了asp.net标签，这意味着你使用的是HTTP调用中的上下文。静态成员背景是在asp.net中不可用，因为你需要同步访问它，因为你的数据上下文是必需的每个的电话，你只能服务一个HTTP响应的时间，可扩展性百年难遇的惨败。

Since you added the asp.net tag, it means you are using the context within a HTTP call. A static member context is unusable in asp.net because you need to synchronize access to it, and since your data context is required by every call, you can only serve one HTTP response at a time, a scalability fiasco of epic proportions.

这就是为什么数据上下文创建和关于这去'处置。事实上，类规格明确调用这种使用方式：

This is why data context are created and disposed 'on-the-go'. In fact, the class specifications clearly calls out this use pattern:

在一般情况下，一个DataContext实例
设计到最后一个
工作单位但是你的应用程序定义
这个词。一个DataContext是
重量轻，不昂贵创建于
。一个典型的LINQ to SQL
应用在方法范围或作为短命类的
会员的
表示一组逻辑相关的
数据库操作创建的DataContext
实例

In general, a DataContext instance is designed to last for one "unit of work" however your application defines that term. A DataContext is lightweight and is not expensive to create. A typical LINQ to SQL application creates DataContext instances at method scope or as a member of short-lived classes that represent a logical set of related database operations.

有关ASP.Net一个明智的单位的工作语境是HTTP调用自身。关于这个主题更长的讨论，可以在的LINQ搜到SQL DataContext的生存期管理。

For ASP.Net a sensible 'unit-of-work' context is the HTTP call itself. A longer discussion on this topic can be found at Linq to SQL DataContext Lifetime Management.

连接的问题，开/关是一个不是问题的问题。通常情况下，连接池和'开放'只不过是一个再利用从池中的连接。如果你打开是重量级的（完全成熟的登录），然后你用池不正确。比较登录/秒并的连接复位/秒计数器将很快显露如果情况确实如此。

The issue of connections open/close is a non-issue. Normally the connections are pooled and the 'opening' is nothing but a re-use of a connection from the pool. If you're opening is heavyweight (fully fledged login) then you're using pooling incorrectly. Comparing Logins/sec and Connection Resets/sec counters will quickly reveal if that is indeed the case.

这篇关于更高效的数据库访问的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！