Linq to SQL：为每个页面或全局页面设置一个小的DataContext会更好吗？

Question

我在一个ASP.NET应用程序中尝试使用Linq to SQL，该应用程序使用包含大量外键（100多个表）的大型数据库。令我印象深刻的是Linq如何允许您创建一个包含所有关系的datacontext，然后创建自动连接表的Linq语句。但是，这会产生一个问题：如果我提交的Linq语句只适用于一个或两个表，那么拥有一个只有必要的表/表的datacontext会更好吗？在我看来，如果我使用数据库中的所有表构建一个datacontext，它将非常庞大，并且每次使用Linq加载它都会对性能产生负面影响。我是对的吗？

评论：我知道只在需要的时候创建datacontext（但是谢谢你提到它）。问题是我是否应该拥有大量的小数据文件，或者是否可以构建一个大数据文件。

Answer 1

每一组已连接的表应该有一个DataContext。在大多数应用程序中，这意味着一个DataContext用于所有内容。如果您碰巧有几组表不需要一起修改，那么您可能会考虑几个DataContexts。如果您甚至可能需要跨DataContexts进行查询，请不要将它们分开。

DataContext不仅仅是一组表 - 它是数据网关模式的一种实现 - 您可以使用返回所需数据的方法填充它，因此您不必将查询硬编码到每个表中。你的申请的一角。现在，如果你有多个DataContexts，每页一个，你很可能最终不得不在每一个中坚持你的常用功能（想想MyDataContext.GetActiveCustomers（））。这将是可怕的重复。

所以答案是构建许多小型DataContexts通常都不行。只有当您的数据完全独立（不同的逻辑或物理数据库）或者您将DataContext简单地用作Connection对象时，这才是可行的，而这并不是理所当然的。

请注意，DataContexts应该是短暂的 - 它们是工作单元模式的实现，因此它们的生命周期应该等于一个逻辑操作（例如，加载一组产品或插入新订单）。 DataContexts创建和销毁起来很便宜，所以不要因为它而浪费时间来缓存它们。

Answer 2

此页面http://www.albahari.com/nutshell/10linqmyths.aspx（参见神话＃10）表示最好使用短暂的DataContext实例。

Answer 3

我相信数据上下文非常轻量级，大多数只是容器。在您查询之前，数据实际上并未加载到上下文中。我不认为拥有单个数据上下文是错误的，而只是根据需要（作为一个工作单元）实例化它而不是一直保持它。这样，你就没有一个可以继续变得越来越大的长寿命对象。

如果您的表可以分成相关的表组，您可能需要考虑为每个组分别设置一个数据上下文。我不确定LINQ如何使用来自多个上下文的数据处理查询，但似乎只要表位于同一服务器上它就应该工作。如果您确实将事情分解为多个上下文并且查询需要多个表格，则必须检查这一点。

通常我会使用单个上下文并根据需要对其进行实例化，但我没有任何与您相同的数据库。

Answer 4

我对我们的数据库进行了测试，该数据库有大约600个表。首先，我将它们分解为9个离散数据上下文，每个上下文都非常易于管理。然后我编写了一个脚本，在其中一个脚本上选择，更新和删除了几百次（在每个脚本之后处理datacontext，以便LINQ被强制为每次访问重新创建它）。

然后我创建了另一个数据文本，其中包含所有600个表 - 然后运行相同的测试。

结果实际上是相同的。我的结论是，较小的datacontexts没有性能提升。使用来自单个datacontext的实体工作肯定要容易得多（虽然不是在设计师视图中 - p！）。