C# 使用EF 6在同一数据库中使用多个DBContext

我已经看到了一些关于这个问题的答案，但是没有一个能直接回答我所看到的。我继承了一个最近的代码库，其中包含一个使代码运行更快的章程。在我看来，数据库中的每个表（一个数据库）都有自己的dbcontext。这些表是高度相关的，我一直看到的主要问题是需要根据表之间的外键关系做出决策。在这种设计方法中，每当涉及到两个表时，开发人员都会为每个上下文使用语句进行嵌套（他擅长自动清理，对吧），从表A中获取数据，然后逐行循环表B以查找匹配项（通常我们对非匹配项感兴趣，这样我们就可以只更新表B），然后继续。我当然见过一个应用程序中使用了多种上下文，但我从未见过这种“模式”，也不明白为什么会使用它。在我重写应用程序的这一部分，使每个表都处于相同的上下文中之前，我觉得我应该做一次理智/现实检查，以确保没有真正坏的怪物在等着我。显然，我什么也找不到。下面是一个伪代码段（表名和列名发生更改的代码）：

---

同样，我倾向于威士忌探戈狐步舞，将表移动到一个DbContext中，并在一次插入中处理这个问题，但这需要假设一个比我所熟悉的更深层次的、非常糟糕的编码。很明显，最初的程序员早已离开了这个行业，我们认为这个行业是完全独立的。但是，他显然是一个非常有经验的开发人员（尽管是Java），所以我不喜欢在我可能缺少的东西的情况下假设他不称职。我的问题是，你能证明这个设计的合理性吗？如果是的话，我应该寻找什么

我建议您创建粗粒度的

DbContext

，但不要将整个模式移动到一个

DbContext

您可以遵循DDD实践，其中一个重要的表作为根，然后它与几个强烈依赖它的相关表一起使用。这种结构称为聚合。在我的设计中，我通常为每个聚合创建一个

DbContext

---

另一方面，应该在需要时重新定义操作，以便每个操作只处理一个聚合。它可以从其他聚合中选取ID，进行查询以收集所需的所有数据，但随后仅对一个聚合进行更改。这种设计方法极大地简化了代码。

这是一个反模式的大时代

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

它彻底违背了成熟或类似映射器的实体框架的目的，该框架旨在跨越关系模型和对象模型之间的鸿沟。此类或映射器专门用于将表格形式的关联（子对象指父对象）映射到面向对象形式的关联（父对象拥有子对象）

---

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

多个DBContext的一个问题是，即使连接字符串相同，您的所有事务都将升级到分布式事务协调器。与本地Sql Server Transaction相比，这会降低性能这正是我的喜好，但我对DDD模式没有太多经验（这就是为什么我需要问这个问题）。谢谢你，你不必100%正确。您可以根据自己的直觉将表分组到

DbContexts

，因为从您所实现的业务操作的角度来看，这是合理的。随着时间的推移，事情会顺利的，别担心。

 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.
        }
    }