Question

Description: I've tried to separate certain domain segments into different DbContexts.

Each has several DbSets, but there are some DbSets that are shared, for example the UserProfile.

The reason for this separation is the speed at which the model is generated and the simplicity (less sets in an object, helps with intellisense).

However, I am not sure about what exactly belongs to the model that is generated.

Q1: Is every entity that is transitionally connected with the entities, for which a DbSet exists in a DbContext, included in the model?

Q2: If so, would that mean that performance-wise it serves no purpose to separate the domain into different contexts, since everything that is connected ends up in the model anyway, no matter which DbSets are stated in the DbContext?

Where can I find more information on how the model is generated? I've read a book on EntityFramework and CodeFirst and couldn't find that specific information...

Was it helpful?

Solution

Answering your first question: yes, all relations are modeled including the entities on both sides, so every entity that's connected by a navigation property to an included entity will also be included in the model regardless if there's a DbSet for it or not.

Entity Framework doesn't force you to create DbSets for all entities. This can be handy if you want to "restrict" child entities to only be accessible through their parents.

Regarding your second question: separating your contexts might still improve performance, if not all entities belonging to one context are reachable via navigation properties of entities belonging to the other context. There could be an additional cost associated with explicitly including more DbSets in a context, too.

You could read (some parts of) the Entity Framework source code, it's open-source and available on CodePlex to learn more about how the model is built.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top