Design Decision: Multiple EF EDMX Files

Question

If you have used the Entity Framework then you know the EDMX is cool. You also know it can become HUGE and almost unmanageable.

When it gets large, it is tempting to create a second EDMX or third - even one for each Schema in your database (just as an example).

Such a seperation would help with organization of your EDMX, but it could seperate the context of entities in the same namespace.

Moreover, seperate EDMX files can create a situation where a JOIN operation across EDMX files results in excessive, redundant database communication.

But, the fact remains, the larger the EDMX, the more difficult it is to use. The more difficult it is to ensure it is correct. The easier it is to break.

Do you break your EDMX files apart? Do you have a rule of thumb for when to it?

Answer 1

One example for the need to split your EDMX would be if you have a group of entities that are used in more than one project, while others are project-specific and you are willing to forsake having navigation properties between the parts (and remain with only exposed FKs).

You can automatically merge the EDMXs into one if you want to maintain the separately, but open up a context to them all and query as one. This requires that they share the same namespace.