在具有EF 6的同一数据库中使用多个dbcontext [英] using multiple dbcontexts in the same database with EF 6

问题描述

我在该问题的一般领域中看到了一些答案，但是没有一个答案能直接解决我所看到的问题.我继承了带有宪章的最新代码库，以使代码运行更快.在我看来，数据库(一个数据库)中的每个表都被赋予了自己的dbcontext.这些表是高度相关的，我一直看到的主要问题是，需要基于表之间的外键关系来制定决策.使用这种设计方法，每当涉及到两个表时，开发人员都会为每个上下文嵌套using语句(对他有利，可以进行自动清理，对)，从表A中获取数据，然后逐行循环遍历表B以查找匹配项(通常我们对不匹配感兴趣，因此我们可以只更新表B)，然后继续.我当然已经看过一个应用程序中使用了多个上下文，但是我从未见过这种模式"，也无法弄清楚为什么要使用它.在我重写应用程序的这一部分以使每个表都处于相同的上下文之前，我觉得我应该做一个健全性/真实性检查，以确保没有真正的坏怪物在等我.显然，我找不到任何东西.这是一个伪代码段(具有更改表名和列名的精确代码):

I've seen a few answers that get in the general area of this question, but none that directly gets at what I'm seeing. I've inherited a recent code base with a charter to make the code run faster. It looks to me like each of the tables in the database (one database) is given its own dbcontext. These tables are highly relational and the major issue I keep seeing is that decisions need to be made based on foreign key relationships between tables. With this design approach, every time two tables are involved, the developer nested using statements for each context (good on him for auto cleanup, right), grabs the data from table A, then, loops through table B row by row to find matches (usually we're interested in the non-matches so that we can just update table B), then proceed. I have certainly seen multiple contexts used in an app, but I've never seen this "pattern" and cannot figure out why one would use it. Before I rewrite this part of the app so that each table is in the same context, I felt I should do a sanity/reality check to make sure that there isn't some really bad monster waiting for me. Obviously, I cannot find anything. Here's a pseudo snippet (exact code with table and column name changes):

 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)，所以当我可能缺少这种能力时，我不喜欢承担无能.我的问题是，您能证明这种设计合理吗?如果是，我应该寻找什么?

Again, my inclination is very much Whiskey-Tango-Foxtrot, move the tables to one DbContext and handle this in one insert, but that requires assuming a deeper level of really, really bad coding than I'm comfortable making. Obviously, the original programmer is long gone from the business and we think the profession entirely. But, he apparently was a pretty experienced developer (Java, though), so I don't like to assume incompetence when it could be something I'm missing. My question is, could you justify this design, and if so, what should I look for?

推荐答案

我建议您制作粗粒度的 DbContexts ，但不要将整个架构移动到一个 DbContext .

I would recommend you to make coarse-grained DbContexts, but not to move entire schema to one DbContext.

您可以遵循DDD惯例，其中将一个重要表作为根，然后将其与几个非常依赖它的相关表结合在一起.该结构称为集合.在我的设计中，我通常每个聚合创建一个 DbContext .

You can follow the DDD practice, where one important table is taken as the root, and then it goes together with a couple of related tables that strongly depend on it. That structure is called an aggregate. In my designs, I usually make one DbContext per aggregate.

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

On the other hand, operations should be redefined where needed, so that each operation only deals with one aggregate. It may pick IDs from other aggregates, make queries to collect all the data it needs, but then make changes to only one aggregate. That approach to design is leading to great simplifications in code.

这篇关于在具有EF 6的同一数据库中使用多个dbcontext的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！