What are the advantages and disadvantages of using one or more DbContext with EF?

Question

VS2013, first code EF6, MVC, (VB)

I wanted to better understand the pros and cons of using either one context or dividing DbSets into multiple contexts. I read some of the old SO posts on several DbContexts and actually did not find what I was looking for; a comprehensive expression about when and where to use or not to use multiple DbContexts.

In the case of a single user running a program, such as Windows Forms, on their own hardware, it would seem that there is no reason to have several contexts for the convenience of working with code.

In the case of a web application that runs the core business program for several enterprises, it would seem that several DbContexts are needed for security and administration.

But I would like to receive confirmation if I think correctly about this issue. All I can think of is the following, but then I am completely new to this environment:

Pluses of one context:

• Coding has only one context for working with
  • (Are there any problems with relationships between contexts?)
• Migrations are easier because there is only one folder and the migration process
• Easier to get a complete diagram built in SSMS or EDMX
  • ( Link here to get EDMX diagrams when using code for the first time)

Ends of one context:

• Security can be a problem for multiple web clients in a corporate application
  • (Is this a problem for simple websites with simple memberships?)
• Some SO posts seem to indicate that response time is a problem
  • (What is the mechanism here?)

That's all I have. I don’t know enough to fully understand both sides, and given the different environments in which we can work, it would seem that the answer to one or more contexts will be different.

I am currently working on a site where members will participate, as well as a downloadable application that will be a personal application on user equipment. In this case, I think that one context for both makes sense, but before I delve into it, I would ask you to discuss this a bit. I believe that others who are a little new to the environment will still have the same questions.

I also note that Microsoft considered it appropriate to add a lot of context features to EF6 and above for EF, so there should clearly be some programming environments that lead to good reasons in order to have multiple contexts.

Thanks for the input.

Best regards, Alan

Answer 1

The only good reason to have multiple contexts, in my opinion, is that you have several databases in the game. For example, one application I'm working with has 3 contexts. Two contexts for existing databases for which the application is not directly responsible, and the third is an application-specific context with migrations.

There is no real benefit to sharing the context. Eric suggests there are performance issues in large contexts, but I worked with a single context with 50+ objects in it and didn't notice any performance issues at all.

However, on the other hand, there are real flaws in working with multiple contexts. Firstly, you lose the ability to work with several objects without problems if they are not in the same context. In addition, multiple contexts tend to confuse the hell out of green developers due to the Entity Framework object graph tracking. For example, suppose you had two objects Foo and Bar , as in separate contexts. If you created a relationship with Bar on Foo :

 public class Foo { public virtual Bar Bar { get; set; } } 

Well guess what? Both Foo and Bar now tracked by the Foo context. If you then try to perform migrations in both contexts, you will get errors because Bar controlled by two, counting, two contexts.

Mistakes like this are ridiculously easy to make, and you will sit down for yourself, trying to completely eliminate everything. In addition, my argument has always been that if you have objects in your project that you can completely exclude from others, then this is an argument for a completely separate project, and not just for a different context.

Answer 2

I saw in the comments that you mentioned Domain Driven Design training. One of the DDD concepts is Limited Contexts (be sure to check the associated resource for bubble contexts to see how to deal with two contexts sharing entities).

It makes absolute sense to map your restricted contexts using a separate DbContext for each. There are certain issues that you should be careful about when doing this, but after the DDD approach, you should avoid them. Primary are common objects. One context should be responsible for managing the life cycle of shared objects, another should only request these objects and not make any changes to them.

Dividing your domain into a limited context will allow you to more easily manage a large / complex domain. It also avoids unnecessary loading of parts of the domain if you do not need them (in SOA, you can autonomously use each restricted context as a service, which Udi Dahan calls Standalone Business Component ).

I would not advocate a split until you have to. For example, several teams working with different parts of a domain at the same time may provide a good opportunity for separation, but at some point it definitely makes sense to do so.