多个 DataContext 类是否合适？

StackOverflow https://stackoverflow.com/questions/1949

题

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

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

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

关于多个 DataContext（对应于数据库命名空间）是否适合代替（或补充）一个非常大的 DataContext 类（对应于整个数据库）有什么想法或经验？

有帮助吗？

解决方案

我不同意约翰的回答。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。

其他提示

当我在旧数据库上改造 LINQ to SQL 时，我一直在争论同样的问题。我们的数据库有点庞大（150 个表），经过一番思考和实验，我选择使用多个 DataContext。这是否被认为是一种反模式还有待观察，但就目前而言，它使生活变得易于管理。

我认为约翰是对的。

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

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

@evan“ dataContext（或linq to objectContext）更像是“工作单位”，而不是一个连接”，这正是为什么您不应该拥有一个以上的DataContext。为什么您一次想要多个“工作单元”？

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

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

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

我主要关心的是，与数据库的特定区域相关的单个操作实例化和处置一个庞大的DataContext类将是对应用程序资源的不必要强加的。

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

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

此外，工作单元概念与原始问题并不真正相关。工作单元通常是指单个 DC 的工作量 实例 正在做的事情，而不是 DC 做了多少工作 班级 是 有能力的 做的事。

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

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top