11

我试图找出关于如何组织 DataContexts 的最佳策略。我们工作的典型数据库有 50 到 100 个表，通常是第三范式，它们之间有很多关系。我认为我们有两个选择：

  1. 将所有表放在一个上下文中。这将确保我们所做的任何事情都将在数据库中以正确的顺序提交。问题是 LINQ 设计器会弄乱 50 多个表，我担心性能可能会受到影响。
  2. 根据表的逻辑分组创建多个数据上下文。问题在于，在某些地方，关系的一侧将在一个上下文中，而另一侧在另一个上下文中。我们必须手动处理以正确的顺序提交两个上下文。

有没有推荐的做法来处理这个问题？

更多细节：

我想在 LINQ to SQL 之上创建自己的实体和工作单元。实体将在 xml 模型文件中定义，其中还将指定到 LINQ 实体的映射。自定义工具将根据模型生成我的实体 (POCO)。客户端代码将仅与我的实体和我的工作单元交互；永远不要直接使用 DataContext 或 LINQ 实体。但是我不想复制 LINQ to SQL 提供的开箱即用的功能，所以我想使用底层的 LINQ DataContext。这意味着我不能在不同的数据上下文中拥有两个订单，因为不可能将我的 POCO 订单与它们都映射。

4

4 回答 4

4

这是一个已在此处彻底分析的常见问题：http: //craftycode.wordpress.com/2010/07/19/linq-to-sql-single-data-context-or-multiple/

本质上，您应该为每个强连接的表组创建最多一个数据上下文，或者每个数据库最多创建一个数据上下文。

于 2010-07-19T15:15:33.203 回答
2

LINQ-to-SQL 映射类似于类型化的数据集，因为当您使用其中一个时，您正在处理一个包含数据的会话。您可以在几个不同的 DataContext 中拥有相同的表。毕竟，它们只是类；在您开始与数据库交互之前，它们没有任何意义，通过用现有数据填充它们或使用它们来创建新数据。

因此，当您发送新目录时，您可能需要处理客户、地址、电话等表。然后，您就有了在创建订单时使用的 Invoice、Line Item、Product 等表格。但是在后一组中，您可能还希望拥有 Customer。没关系。您应该注意一次只有一个会话处于活动状态，这样您就不会使用不一致的数据。只要您不以重叠的方式使用它们，您就不应该在各种 DataContexts 中遇到重叠实体的问题。

就混乱而言，您可以将 DataContext 放在特定的命名空间中，也可以将各种实体放在特定的命名空间中（尽管 DataContext 中的每组实体只有一个命名空间）。您可以在“属性”窗口中执行此操作。这将使您保持 Intellisense 不那么混乱。

于 2008-10-24T14:50:16.077 回答
0

您应该创建允许您执行工作单元的上下文。这可能涉及重叠的表映射。

上下文1：客户有很多发票

上下文2：客户有很多订单

上下文3：发票有很多订单

于 2008-10-24T14:30:41.687 回答
0

我每个数据库使用一个数据上下文。

平均表最多可达 100 个，但根据经验，我没有遇到任何性能问题。

数据上下文位于一个单独的项目中，该项目已编译。从 BLL 引用的结果 dll

于 2009-04-18T20:07:54.213 回答