使用多个dbcontexts在同一个数据库与EF 6

我已经看到了这个问题的一般面积得到一些答案，但没有直接获得在我所看到的。我使用章程继承了最近的代码库，以使代码运行得更快。它看起来像数据库中的每个表（一个数据库）都有自己的dbcontext。这些表格是高度相关的，我所看到的主要问题是需要根据表之间的外键关系做出决定。通过这种设计方法，每次涉及两个表时，开发人员为每个上下文嵌套使用语句（正确的自动清理），从表A抓取数据，然后逐行循环遍历表B以查找匹配（通常我们对非匹配感兴趣，以便我们可以更新表B），然后继续。我当然看到了应用程序中使用了多个上下文，但我从来没有见过这种“模式”，并且无法弄清楚为什么会使用它。在我重写应用程序的这部分内容以使每个表格都处于相同的背景下之前，我觉得我应该做一个理智/现实检查，以确保没有一些非常糟糕的怪物在等着我。显然，我找不到任何东西。下面是一个伪代码段（与表和列名称的变化确切的代码）：使用多个dbcontexts在同一个数据库与EF 6

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

同样，我的倾向是非常威士忌，探戈，狐步舞，将表一的DbContext和一个刀片处理这个问题，但需要假设更深层次的真正非常糟糕的编码，而不是我自己做的。显然，原来的程序员早已不在业务之列，我们完全认为这个职业。但是，他显然是一个非常有经验的开发人员（不过，Java），所以我不喜欢在我可能缺少某些东西的时候认为无能。我的问题是，你能否证明这个设计是正确的？如果是这样，我应该寻找什么？

来源

2017-02-17 Ron

一个问题是，所有的交易将得到提升，即使在连接字符串是相同的分布式事务协调器。与本地Sql Server交易相比，这会损害您的表现 – Fran

我建议你制作粗粒DbContexts，但不要将整个架构移动到一个DbContext。

您可以按照DDD的做法，其中一个重要的表被作为根，然后将其与一对夫妇在很大程度上取决于它相关的表一起去。该结构被称为聚合。在我的设计中，我通常每聚合一个DbContext。

在另一方面，操作应重新定义需要的地方，让每个操作只有一个总的交易。它可以从其他聚合中挑选ID，进行查询以收集所需的所有数据，但只对一个聚合进行更改。这种设计方法导致代码的极大简化。

来源

2017-02-17 15:19:00

完全是我的倾向，但我没有很多DDD模式的经验（这就是为什么我需要问这个问题）。谢谢。 – Ron

你不必100％正确地做到这一点。您可以根据自己的实际情况和组表将您的直觉和组表视为“DbContexts”，因为您从您正在实施的业务操作的角度来看是合理的。随着时间的推移，事情会顺利进行，不用担心。 –

这是一个反模式，大的时间！

我见过初学者为此，ESP。当来自DAO背景时，每个实体都有自己的数据访问镜像。

它彻底失败成熟OR映射器等实体框架的目的，其被设计为交叉关系模型和对象模型之间的鸿沟。这样的OR映射器被设计为，特别是以表格形式（儿童指父母）将关联映射到面向对象形式（父母拥有子女）的关联。

所以，是的，继续前进，抓住相关的实体为代表应用程序中的天然骨料上下文。

多DbContexts

来源

2017-02-17 15:25:40

使用多个dbcontexts在同一个数据库与EF 6

回答

相关问题