33

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

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

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

关于多个 DataContexts（对应于 DB 命名空间）是否适合代替（或补充）一个非常大的 DataContext 类（对应于整个 DB）的任何想法或经验？

4

5 回答 5

28

我不同意约翰的回答。DataContext（或 Linq to Entities ObjectContext）更像是一个“工作单元”，而不是一个连接。它管理更改跟踪等。有关说明，请参阅此博客文章：

LINQ to SQL DataContext 的生命周期

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

  1. 非常适合“工作单元”方法
  2. 也是为“无状态”服务器操作而设计的
  3. 不是为长期使用而设计的
  4. Should be used very carefully after
any SumbitChanges() operation.

考虑到这一点，我不认为使用多个 DataContext 会造成任何危害——事实上，为不同类型的工作创建不同的 DataContext 将有助于使您的 LinqToSql 实现更有用和更有条理。唯一的缺点是你不能使用 sqlmetal 来自动生成你的 dmbl。

于 2008-08-07T21:02:30.057 回答
5

我一直在为同一个问题争论不休，同时在遗留数据库上对 LINQ to SQL 进行改造。我们的数据库有点庞大（150 个表），经过一番思考和实验，我选择使用多个 DataContext。这是否被认为是一种反模式还有待观察，但现在它使生活变得可控。

于 2008-08-05T22:51:08.217 回答
4

我认为约翰是正确的。

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

你如何支持这种说法？您的哪些实验表明大型 DataContext 是性能瓶颈？拥有多个数据上下文很像拥有多个数据库，并且在类似的场景中是有意义的，也就是说，几乎没有。如果您正在使用多个数据上下文，则需要跟踪哪些对象属于哪个数据上下文，并且您无法关联不在同一数据上下文中的对象。这是一种昂贵的设计气味，没有真正的好处。

@Evan“DataContext（或Linq to Entities ObjectContext）更像是一个“工作单元”而不是一个连接“这正是你不应该拥有多个数据上下文的原因。为什么您一次需要多个“工作单元”？

于 2008-08-27T01:11:45.710 回答
4

我不得不不同意接受的答案。在提出的问题中，系统有一个大型数据库，几乎每个表之间都有很强的外键关系（我工作的情况也是如此）。在这种情况下，将其分解为更小的 DataContext（DC）有两个直接和主要的缺点（问题都提到了）：

  1. 您失去了某些表之间的关系。您可以尝试明智地选择 DC 边界，但您最终会遇到这样一种情况，即使用从一个 DC 中的表到另一个 DC 中的表的关系非常方便，而您将无法这样做。
  2. 一些表格可能出现在多个 DC 中。这意味着，如果您想在部分类中添加特定于表的帮助方法、业务逻辑或其他代码，则这些类型将无法跨 DC 兼容。您可以通过从其自己的特定基类继承每个实体类来解决此问题，这会变得混乱。此外，架构更改必须在多个 DC 之间复制。

现在这些都是显着的缺点。是否有足够大的优势来克服它们？问题提到了性能：

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

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

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

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

于 2014-06-17T20:53:53.990 回答
2

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

于 2008-08-05T09:57:03.333 回答