Linq-to-SQL：有多少数据上下文？答案

【问题标题】：Linq-to-SQL: how many datacontexts?Linq-to-SQL：有多少数据上下文？
【发布时间】：2010-05-29 14:26:22
【问题描述】：

我有一个包含超过 300 个表的 SQL Server 2008 数据库。我必须设计的应用程序是一个 Windows 窗体应用程序、.NET 3.5、C#。

使用 Linq-to-SQL 的最佳方式是什么？

我打算为每个业务实体创建一个数据上下文。

有什么问题吗？

我需要知道这种使用 Linq-to-SQL 的方式是否有任何缺点或会产生性能问题？

谢谢。

【问题讨论】：

west-wind.com/weblog/posts/246222.aspx

标签： c# sql sql-server linq-to-sql

【解决方案1】：

每个数据库通常应该有 1 个单独的 DBML 文件（=数据上下文）。您当然不应该为每个业务实体创建一个DataContext，因为这样做会使您失去 LINQ to SQL 的大部分有用功能，例如内存事务（工作单元）、延迟加载以及对多个实体执行 LINQ 查询。

您有一个相当大的模型（+300 个表），这意味着很多实体。很多实体都不是什么大问题，除了 LINQ to SQL 设计器。将设计师与如此大的模型一起使用可能会很烦人。这可能是将域拆分为多个子域（每个子域都有一个 DBML 文件）的原因，但肯定不是每个实体一个。但是，请记住，您在域边界处失去了 L2S 功能。

过去，我曾建议一个团队将 +150 个实体域拆分为 5 个 DBML 文件，然后将它们重新合并为一个 DBML。编辑模型的痛苦增加了，但使用多个 DataContexts 的痛苦消失了，这大大减轻了他们的整体痛苦。

【讨论】：

谢谢。请问，“编辑模型的痛苦”到底是什么意思？我认为在子域中拆分大数据模型可以解决一些性能问题。您是否有在需要 100 多个并发用户的 win forms/SQL Server 数据库中使用大数据模型/单个 DBML 文件的经验？谢谢。
您创建的数据上下文类的数量对性能没有任何影响。
我同意本的观点。我无法想象拥有多个 DBML 会对性能产生任何影响。请解释你为什么这么认为。

【解决方案2】：

为每个业务实体创建一个数据上下文是没有意义的，每个数据库只需要一个数据上下文。

【讨论】：

【解决方案3】：

这取决于有多少用户同时使用您的数据库，而不是有多少表。所以这都是关于典型的数据库问题：连接数、锁定和其他东西。

【讨论】：

我不认为他在谈论实例化 DataContext，而是为每个实体定义一个 DBML 文件。
是的，为每个实体定义一个 DMBL 文件。谢谢。

【解决方案4】：

我现在对整个数据库使用 1，但拥有更多也有合法用途。例如，我在安装连接到远程数据库并导入数据并将数据转换为新格式以进行部署的站点时运行一个脚本。该进程使用一些临时表。

通过将临时表放在单独的上下文中，一旦部署了站点，我就可以简单地删除这些上下文和代码，因为它们是独立的实体。

【讨论】：