logo标签列表

多个DataContext类是否适用？

asp.net.netlinq-to-sqldatacontext
32
为了在ASP.net 3.5应用程序中充分使用LinqToSql，需要创建DataContext classes（通常使用VS 2008中的设计工具完成）。从UI角度看，DataContext是您想通过LinqToSql公开的数据库部分的设计，并且在设置LinqToSql的ORM功能方面是不可或缺的。
我的问题是：我正在设置一个使用大型数据库的项目，其中所有表都通过外键相互连接。我的第一反应是制作一个巨大的DataContext类来模拟整个数据库。这样，理论上我可以使用通过LinqToSql生成的外键连接轻松地在代码中转换相关对象、插入相关对象等（虽然我不知道这在实践中是否有必要）。
然而，经过一些思考，我现在认为创建多个DataContext类可能更有意义，每个类与数据库中的特定命名空间或逻辑相关部分相关联。我的主要担忧是，为了与数据库的特定区域进行单独操作，每次实例化和处理一个巨大的DataContext类都会对应用程序资源造成不必要的压力。此外，创建和管理较小的DataContext文件比一个大文件更容易。我将失去的是，在LinqToSql中无法浏览一些远程数据库部分（即使一系列关系将它们连接在实际数据库中）。此外，有些表类将存在于多个DataContext中。
你是否有任何想法或经验，是否应该使用多个DataContext（对应于DB名称空间）来替代（或除了）一个非常大的DataContext类（对应于整个DB）？
5个回答
28
我不同意John的回答。DataContext（或Linq to Entities ObjectContext）更像是“工作单元”而不是连接。它管理变更追踪等。请参阅此博客文章获取描述：LINQ to SQL DataContext的生存期。该博客文章的四个主要观点是：DataContext：
  1. 最适合“工作单元”方法
  2. 也设计用于“无状态”服务器操作
  3. 不适用于长时间使用 
Should be used very carefully after
any SumbitChanges() operation.

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

5

在将LINQ to SQL应用于遗留数据库时，我一直在纠结同一个问题。我们的数据库有点庞大（150张表），经过一番思考和实验后，我决定使用多个DataContext。目前尚不清楚这是否被视为反模式，但现在它让生活更加可管理。

4
我不同意被接受的答案。在所提出的问题中，系统有一个具有强外键关系的单个大型数据库，几乎每个表之间都有联系（我所在的情况也是如此）。在这种情况下，将其分解成更小的DataContexts（DC）具有两个直接和重要的缺点（问题中均提到）：
  1. 您会失去某些表之间的关系。 您可以尝试明智地选择DC边界，但最终您将遇到一种情况，即从一个DC中的一个表使用关系到另一个表非常方便，但您将无法使用。
  2. 某些表可能会出现在多个DC中。 这意味着，如果您想在部分类中添加特定于表的帮助程序方法、业务逻辑或其他代码，则类型在DC之间不兼容。您可以通过从其自己的特定基类继承每个实体类来解决此问题，但这会变得混乱。此外，模式更改必须在多个DC中复制。

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

我的主要关注点是，为了与数据库特定区域相关的单个操作而实例化和处理一个巨大的DataContext类会对应用程序资源施加不必要的负担。
事实上，在典型的工作单元中，大DC实例化或使用不需要更多的时间。实际上，在运行过程中创建第一个实例后，相同DC的后续副本几乎可以瞬间创建。
对于具有彻底外键关系的单个大型数据库，多个DC的唯一真正优势在于您可以更好地将代码分隔。但是，您已经可以使用部分类来实现此目的。
另外，工作单元概念与原始问题实际上并不相关。工作单元通常指单个DC实例正在执行多少工作，而不是DC类能够执行多少工作。
4
我认为John是正确的。
“我的主要关注点是，为了涉及到数据库特定区域的个别操作，每次实例化和释放一个巨大的DataContext类都会对应用程序资源造成不必要的负担。”
你如何支持这一说法？你有什么实验证据表明，一个大的DataContext是性能瓶颈吗？拥有多个datacontext很像拥有多个数据库，在类似的情况下是有道理的，也就是几乎从来没有。如果你正在使用多个datacontext，则需要跟踪哪些对象属于哪个datacontext，并且不能关联不在同一数据上下文中的对象。这是一种昂贵的设计味道，没有实际的好处。
@Evan，“DataContext（或Linq to Entities ObjectContext）更像是“工作单元”而不是连接” 这正是为什么你不应该拥有多个datacontext的原因。为什么你想要同时拥有多个“工作单元”呢？
是的，楼主在假设大型DC需要更长时间实例化方面是不正确的。事实上，在运行过程中创建第一个实例之后，同一DC的后续实例几乎可以即时创建。 - Jordan Rieger
2

在我使用LINQ to SQL和LINQ to Entities的经验中，DataContext与数据库连接是同义词。因此，如果您要使用多个数据存储，则需要使用多个DataContexts。我的直觉是，如果一个DataContext涵盖了大量的表，您不会注意到太多的减速。但是，如果您确实遇到了问题，可以在能够隔离没有与其他表集相关联的表的点上逻辑上分割数据库，并创建多个上下文。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接