关于asp.net：是否有多个DataContext类合适？

Are Multiple DataContext classes ever appropriate?

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

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

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

是否对替代一个大型DataContext类(对应于整个DB)(或除此之外)是否适合使用多个DataContext(对应于DB名称空间)有任何想法或经验？

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

LINQ to SQL DataContext的生命周期

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

非常适合
对于"工作单元"方法

也专为
"无状态"服务器操作

不适合
使用寿命长

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

考虑到这一点，我认为使用多个DataContext不会造成任何损害，实际上，为不同类型的工作创建不同的DataContext将有助于使您的LinqToSql实现更具可用性和组织性。唯一的缺点是您将无法使用sqlmetal自动生成dmbl。

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

我不同意接受的答案。在提出的问题中，系统只有一个大型数据库，几乎每个表之间都有很强的外键关系(在我工作的情况下)。在这种情况下，将其分解为较小的DataContexts(DC)有两个直接和主要的缺点(均由问题提到)：

您会丢失某些表之间的关系。您可以尝试明智地选择DC边界，但是最终会遇到这样的情况，即使用从一个DC中的表到另一个DC中的表的关系会非常方便，而您将无法使用这种关系。

有些表可能出现在多个DC中。这意味着，如果要在部分类中添加表特定的帮助器方法，业务逻辑或其他代码，则这些类型将在DC之间不兼容。您可以通过从每个实体类自己的特定基类继承每个实体类来解决此问题，这会很麻烦。而且，架构更改将必须在多个DC之间重复。

现在，这些都是重大缺陷。有足够大的优势来克服它们吗？问题提到性能：

My main concern is that instantiating and disposing one huge
DataContext class all the time for individual operations that relate
to specific areas of the Database would be impose an unnecessary
imposition on application resources.

实际上，在一个典型的工作单元中实例化或使用大量的DC需要花费大量时间是不正确的。实际上，在运行的过程中创建第一个实例之后，几乎可以立即创建同一DC的后续副本。

具有完全外部键关系的单个大型数据库的多个DC的唯一真正优势是，您可以更好地划分代码。但是您已经可以使用局部类来做到这一点。

同样，工作单元概念与原始问题并不真正相关。工作单元通常是指单个DC实例正在执行的工作量，而不是DC类能够执行的工作量。

我认为约翰是正确的。

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

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

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

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