c# - 使用 EF 6 在同一个数据库中使用多个 dbcontext

Question

我看到了一些涉及这个问题的一般领域的答案，但没有一个能直接说明我所看到的。我继承了一个最近的代码库，其中包含一个使代码运行得更快的章程。在我看来，数据库(一个数据库)中的每个表都被赋予了自己的 dbcontext。这些表是高度相关的，我一直看到的主要问题是需要根据表之间的外键关系做出决策。使用这种设计方法，每次涉及两个表时，开发人员为每个上下文嵌套 using 语句(对他来说自动清理很好，对)，从表 A 中获取数据，然后逐行循环遍历表 B 以找到匹配项(通常我们对不匹配感兴趣，这样我们就可以更新表 B)，然后继续。我当然见过一个应用程序中使用了多个上下文，但我从未见过这种“模式”，也无法弄清楚为什么要使用它。在我重写应用程序的这一部分以使每个表都在相同的上下文中之前，我觉得我应该进行健全性/现实性检查以确保没有一些非常糟糕的怪物在等着我。显然，我找不到任何东西。这是一个伪代码段(表和列名称更改的确切代码):

 var beers = from b in beerContext.AllBeersOffered
    where b.CurrentStock = 1
    select b;
    foreach(var beer in beers)
    {
        Bars bars = barContext.AllBeersCarried.FirstOrDefault(x=>x.BeerId==beer.Id)
        if(bars == null)
        { 
            //Create a List of beers offered but not carried in that bar, 
            // which is then added to another table.
        }
    }

同样，我的倾向是 Whiskey-Tango-Foxtrot，将表移动到一个 DbContext 并在一个插入中处理它，但这需要假设比我能轻松编写的更深层次的非常非常糟糕的编码。显然，原来的程序员早已离开这个行业，我们完全认为这个职业。但是，他显然是一位非常有经验的开发人员(不过是 Java)，所以我不想假设自己能力不足，因为这可能是我所缺少的。我的问题是，你能证明这种设计是合理的吗？如果是这样，我应该寻找什么？

Answer 1

这是一个反模式，很重要!

我见过初学者这样做，尤其是。当来自 DAO 背景时，其中每个实体都有自己的数据访问镜像。

它彻底违背了像 Entity Framework 这样成熟的 OR 映射器的目的，它旨在跨越关系模型和对象模型之间的鸿沟。此类 OR 映射器特别旨在将表格形式的关联(子项指的是父项)映射到面向对象形式的关联(父项拥有子项)。

是的，继续将相关实体抓取到表示应用程序中自然聚合的上下文中。