logo标签列表

多个/单个 Linq to SQL DataContext 实例化问题

c#linq-to-sql
32

我有一个项目，其中许多不同的类查询和修改一组公共表中的数据。我已经设置了一个.dbml文件，为我们提供了一个DataContext类。我的问题是所有对象是否应该使用单个DataContext实例，还是可以安全地使用多个实例。如果只有一个DataContext，我也想知道线程安全性是否存在，并且是否应该同步访问它的方法。

5个回答
33
Rick Strahl写了一篇很好的文章，关于你的选择: http://www.west-wind.com/weblog/posts/246222.aspx。
另请参阅：LINQ to SQL - where does your DataContext live?。
对于每种类型的部署(网页、桌面、Windows服务等)，您可能需要采用稍微不同的策略。
总之，您的选择如下：
  • 全局DataContext - 在多线程环境中(包括Web应用程序)存在风险。请记住，实例成员不能保证是线程安全的(来自Bradley Grainger在上述答案中的回答)。
  • 每个线程一个DataContext - 复杂。如果您的DataContext正在跟踪更改，则必须确保在适当的时候刷新更改。实例化、存储和检索DataContext很麻烦。
  • 每个原子操作一个DataContext - 您失去了跟踪更改的能力，因为一个DataContext创建对象，而另一个更新或删除它。将数据对象附加到新DataContext上可能不会像您期望的那样正常工作。
  • 每个数据对象一个DataContext - 看起来不太简洁，因为您必须在实例化(创建和附加)和更新/删除时(将其从数据对象上取下并使用它)与DataContext打交道。
我选择了一个DataContext per data object。这可能不是最花哨的解决方案，但它适用于所有的部署环境。
9

我在每次事务中都使用一个新的DataContext实例。

重复使用旧实例会带来麻烦，而且会使DataContext的内容变得臃肿，因为任何曾经加载过的项目都必须被跟踪 - 应用程序会变得越来越慢，并且内存会不断膨胀。

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

8

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

3
使用单个数据上下文对象的问题在于，如果您已将某些更改添加到其队列中，并希望仅对其中的一些排队更改进行回滚，则可能会遇到麻烦。
这就是为什么我为每个类使用一个数据上下文对象-我的“用户”类有自己的数据上下文，我的“应用程序”类也有自己的数据上下文等等。
这种模式消除了在我的项目中执行回滚时的大部分问题。
-3

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

我相信这里的一些linq大师可能能够给出确切的原因，为什么你应该只有一个数据上下文类的实例...但我不是很确定。

这太模糊和迷信了。你能更具体地解释为什么采取这种方法吗？ - Dan Esparza
4
我一直听说的却是相反的。 DataContexts旨在尽可能短暂，以最小化并发问题。 - Konamiman
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接