为了在ASP.net 3.5应用程序中完全使用LinqToSql，必须创建DataContext类(通常在VS 2008中使用设计器来完成)。从UI角度来看，DataContext是我们要通过LinqToSql公开的数据库部分的设计，并且是设置LinqToSql的ORM功能所不可或者缺的。

我的问题是：我正在建立一个使用大型数据库的项目，该数据库中的所有表都通过外键以某种方式相互连接。我的第一个倾向是制作一个巨大的DataContext类，以对整个数据库进行建模。这样，我在理论上可以(尽管我不知道在实践中是否需要这样做)可以使用通过LinqToSql生成的外键连接轻松地在代码中的相关对象之间切换，插入相关对象等。

但是，经过深思熟虑后，我现在认为创建多个DataContext类可能更有意义，每个类都与数据库中特定的名称空间或者逻辑上相关的部分相关。我主要关心的是，对于与数据库的特定区域有关的单个操作，始终实例化和处置一个巨大的DataContext类将对应用程序资源造成不必要的影响。此外，与大文件相比，创建和管理较小的DataContext文件更容易。我会失去的是，数据库的某些遥远部分无法通过LinqToSql进行导航(即使关系链在实际数据库中将它们连接在一起)。此外，在多个DataContext中将存在一些表类。

关于是否需要多个DataContext(对应于DB名称空间)代替一个非常大的DataContext类(对应于整个DB)(或者除此之外)，是否有任何想法或者经验？

解决方案

回答

以我在LINQ to SQL和LINQ to Entities方面的经验，DataContext是与数据库连接的同义词。因此，如果要使用多个数据存储，则需要使用多个DataContext。我的直觉是我们不会注意到包含大量表的DataContext的速度变慢。但是，如果这样做了，我们总是可以在逻辑上拆分数据库，在这些地方可以隔离与其他表集没有任何关系的表并创建多个上下文。

回答

我一直在为同一个问题争论不休，而在旧式数据库上将LINQ改造为SQL。我们的数据库有点麻烦(150张表)，经过一番思考和试验，我选择使用多个DataContext。是否将其视为反模式还有待观察，但就目前而言，它使生活变得可控。

回答

我不同意约翰的回答。 DataContext(或者实体对象的Linq)比连接更像是一个"工作单元"。它管理变更跟踪等。有关说明，请参见此博客文章：

LINQ to SQL DataContext的生命周期

这篇博客文章的四个要点是DataContext：

• 非常适合"工作单元"方法
• 还设计用于"无状态"服务器操作
• 不适用于长期使用

Should be used very carefully after
any SumbitChanges() operation.

考虑到这一点，我认为使用多个DataContext不会带来任何危害，为不同类型的工作创建不同的DataContext可以使LinqToSql实现更加易用和更有条理。唯一的缺点是我们将无法使用sqlmetal自动生成dmbl。

回答

我认为约翰是正确的。

"我主要担心的是，对于与数据库的特定区域有关的单个操作，始终实例化和处置一个巨大的DataContext类会给应用程序资源带来不必要的影响"

我们如何支持该声明？实验表明大型DataContext是性能瓶颈吗？拥有多个数据上下文与拥有多个数据库非常相似，并且在类似情况下(几乎从未如此)是有意义的。如果使用多个数据上下文，则需要跟踪哪些对象属于哪个数据上下文，并且不能关联不在同一数据上下文中的对象。那是昂贵的设计气味，没有真正的好处。

@Evan" DataContext(或者对实体ObjectContext的Linq)更像是一个"工作单元"，而不是连接"
这就是为什么我们不应该拥有多个数据上下文的原因。我们为什么一次要一个以上的"工作单元"？