是否有任何理由使用一个 DataContext 实例,而不是几个?

Posted

技术标签:

【中文标题】是否有任何理由使用一个 DataContext 实例,而不是几个?【英文标题】:Is there any reason to use one DataContext instance, instead of several? 【发布时间】:2011-01-01 13:47:53 【问题描述】:

例如,我有 2 个方法使用一个 DataContext(Linq to sql)。

 using(DataContext data = new DataContext)
   // doing something
   another_datamethod(data);
 

 void another_datamethod(DataContext data)
   // doing
 

使用这种风格?或者以相同的结果,我可以创建单独的“使用 DataContext”。如果我使用一个 DataContext,我会获得什么好处?也许有一些缓存的可能性?

【问题讨论】:

【参考方案1】:

最近,由于多个问题(包括创建与查找表关联的记录),我阅读了大量文章和博客,“强烈建议”您为应用程序使用多个 DataContext。当我学习 LINQ-to-SQL 时,它对我来说最吸引人的品质之一就是能够将我的完整数据库模式导入到一个“大”DataContext 中。所以,这就是我所做的……但几个月后,出现了相互矛盾的信息,说我所做的是一件坏事。怎么办,怎么办……

九个月后,这就是我的立场。我的单个大 DataContext 仍然是我的单个大 DataContext。我有 30 多个数据存储库类访问其中包含的 60 多个表,但我仍然没有看到一个合理的理由来分解我现有的数据域,或者不使用单个 DataContext 处理下一个项目。文章和博客作者遇到的问题是有效的问题。然而,就像大多数技术性的事情一样,做事情的方式永远不会只有一种。我的时间和精力最好的投资是学习并真正了解 LINQ-to-SQL 是如何工作的。我发现可以帮助我做到这一点的最好的书是 Joseph C. Rattz, Jr 的《Pro LINQ: Language Integrated Query in C# 2008》。LINQ-to-SQL 的介绍详细而清晰,并且有大量示例可以阐明这个谜团。

因此,在您的情况下,创建一个大的 DataContext 或创建许多较小的 DataContext...由您决定。较小的显然提供了更好的重用机会,而较大的则有助于增加您专注于业务逻辑和演示代码的时间。

【讨论】:

我在这里不说大或小。我的问题是:堆栈的所有方法中的一个实例或每个方法中的多个实例。 抱歉给您带来了困惑...如果您想针对同一个 DataContext 执行多个方法,您肯定要使用 using 块。使用您的示例将 DataContext 作为参数传入需要为每个方法调用在本地初始化对象。您可以选择将单个全局 DC 作为单例对象,但如果元对象在使用后未刷新,则可能会产生并发问题。 using 块确保 DC 实例在使用后将被丢弃。我会同意的......【参考方案2】:

Datacontexts 跟踪更改并进行缓存,因此可以根据您正在执行的工作进行缓存。

【讨论】:

以上是关于是否有任何理由使用一个 DataContext 实例,而不是几个?的主要内容,如果未能解决你的问题,请参考以下文章

是否有任何实际理由为 JSON 键使用带引号的字符串?

是否有任何理由继续使用 IntentService 处理 GCM 消息?

是否有任何陷阱或充分的理由不使用 autosproc 进行存储过程调用?

是否有任何理由锁定队列?

是否有任何理由对同一资源使用“Vary: *”和“Vary: Foo”响应?

是否有任何理由使用 (nr & 1 == 0) 而不是 (nr % 2 == 0) 来检查奇偶校验?