C# Linq to SQL DataContext 的多/单实例

Multiple/single instance of Linq to SQL DataContext

提问by spender

I have a project with a number of different classes querying and modifying data in a common set of tables. I've set up a .dbml file which provides us with a DataContext class. My question is whether a single instance of the DataContext should be used by all objects, or whether multiple instances are safe to use. I'm also wondering about thread safety in the case of a single DataContext, and whether access to it's methods should be synchronized.

我有一个项目，其中包含许多不同的类，用于查询和修改一组通用表中的数据。我已经设置了一个 .dbml 文件，它为我们提供了一个 DataContext 类。我的问题是 DataContext 的单个实例是否应该被所有对象使用，或者多个实例是否可以安全使用。我还想知道在单个 DataContext 情况下的线程安全性，以及是否应该同步对其方法的访问。

采纳答案by Corbin March

Rick Strahl has a nice article about your options: http://www.west-wind.com/weblog/posts/246222.aspx.

Rick Strahl 有一篇关于您的选择的好文章：http: //www.west-wind.com/weblog/posts/246222.aspx。

See also: LINQ to SQL - where does your DataContext live?.

另请参阅：LINQ to SQL - 您的 DataContext 在哪里？.

You may want a slightly different strategy for each type of deployment - web, desktop, windows service...

对于每种类型的部署，您可能需要略有不同的策略 - Web、桌面、Windows 服务...

Summarized, your options are:

总之，您的选择是：

• Global DataContext - dangerous in multi-threaded environments (including web apps). Remember that instance members are not guaranteed to be thread-safe (from Bradley Grainger's answerabove).
• DataContext per thread - complicated. If your DataContext is tracking changes you must be sure to flush them at the appropriate time. Instantiating, storing, and retrieving the DataContext is a pain.
• DataContext per atomic action - you lose the ability to track changes since one DataContext creates an object while another updates or deletes it. Attaching a data object to a new DataContext may not work like you expect.
• DataContext per data object - seems inelegant because you have to fuss with the DataContext on instantiation(create and attach) and update/delete (pull it off the data object and use it).

• Global DataContext - 在多线程环境（包括 Web 应用程序）中很危险。请记住，实例成员不能保证是线程安全的（来自上面Bradley Grainger 的回答）。
• 每个线程的 DataContext - 复杂。如果您的 DataContext 正在跟踪更改，您必须确保在适当的时间刷新它们。实例化、存储和检索 DataContext 很痛苦。
• 每个原子操作的 DataContext - 您无法跟踪更改，因为一个 DataContext 创建一个对象，而另一个更新或删除它。将数据对象附加到新的 DataContext 可能不会像您期望的那样工作。
• 每个数据对象的 DataContext - 似乎不雅，因为您必须在实例化（创建和附加）和更新/删除（将其从数据对象中拉出并使用它）时对 DataContext 大惊小怪。

I opted for a DataContext per data object. It may not be the fanciest solution but it works in all deployment environments.

我为每个数据对象选择了一个 DataContext。它可能不是最好的解决方案，但它适用于所有部署环境。

回答by Rafe

I've always heard that you should use a single instance of the DataContext. I usually create a singleton instance of my DC in my business logic class, and use it for all my linq queries.

我一直听说您应该使用 DataContext 的单个实例。我通常在我的业务逻辑类中创建我的 DC 的单例实例，并将它用于我的所有 linq 查询。

I'm sure some of the linq gurus on here might be able to give you exact reasons as to why you should only have on instance of your data context class... I'm not quite certain.

我敢肯定这里的一些 linq 专家可能会给你确切的理由，说明为什么你应该只拥有你的数据上下文类的实例......我不太确定。

回答by cllpse

The problem with using a single data-context object is that you can get in trouble if you've added some changes to it's queue, and want to do a roll-back on just someof those queued changes.

使用单个数据上下文对象的问题在于，如果您向它的队列添加了一些更改，并且只想回滚其中一些排队的更改，您可能会遇到麻烦。

That's why I use a data-context object for each of my classes--my Userclass has it's own data-context, my Applicationclass has it's own, and so forth.

这就是为什么我为我的每个类使用一个数据上下文对象——我的User类有它自己的数据上下文，我的Application类有它自己的，等等。

This pattern eliminates most troubles of doing roll-backs in my projects.

这种模式消除了在我的项目中进行回滚的大部分麻烦。

回答by Mark Cidade

The DataContext class is lightweight enough that you can instantiate it over and over. This makes thing simpler when accessing entity objects within a single method. If you need to access the same LINQ objects from different classes and methods while keeping them attached to the DataContext for tracking purposes, it's also okay to keep a single instance.

DataContext 类足够轻量级，您可以反复实例化它。在单个方法中访问实体对象时，这使事情变得更简单。如果您需要从不同的类和方法访问相同的 LINQ 对象，同时将它们附加到 DataContext 以进行跟踪，那么保留单个实例也是可以的。

回答by Sam

I use an new instance of DataContext for every transaction.

我为每个事务使用一个新的 DataContext 实例。

Reusing old instances can be troublesome, and will bloat the content of the DataContext, since any item that has been loaded at some time, will have to be tracked - your app will get slower and slower, bloating up memory.

重用旧实例可能会很麻烦，并且会使 DataContext 的内容膨胀，因为在某个时间加载的任何项目都必须被跟踪 - 您的应用程序会变得越来越慢，从而导致内存膨胀。

If you need an item longer than for a transaction, you can detach it from the DataContext by cloning the item, and can reattach it later to a new and fresh DataContext using Attach().
I even can clone an item, send it over the network with WCF, get it back in some later call, attach it to a new DataContext and save the changes (of course I need a timestamp column for this).

如果您需要一个比事务更长的项目，您可以通过克隆该项目将它从 DataContext 中分离出来，然后可以使用 Attach() 将它重新附加到新的 DataContext。
我什至可以克隆一个项目，使用 WCF 通过网络发送它，在稍后的调用中取回它，将它附加到一个新的 DataContext 并保存更改（当然我需要一个时间戳列）。