using multiple dbcontexts in the same database with EF 6

问题

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

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?

回答1:

I would recommend you to make coarse-grained DbContexts, but not to move entire schema to one 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.

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.

回答2:

This is an anti-pattern, big time!

I've seen beginners do this, esp. when coming from a DAO background, in which each entity has its own data-access mirror.

It thoroughly defeats the purpose of a mature OR mapper like Entity Framework, that is designed to cross the chasm between a relational model and an object model. Such OR mappers are designed especially to map associations in tabular form (child refers to parent) to associations in object-oriented form (parent owns children).

So yes, go ahead and grab related entities into contexts that represent natural aggregates in the application.

来源：https://stackoverflow.com/questions/42301354/using-multiple-dbcontexts-in-the-same-database-with-ef-6