CODEWITHSUNDEEP
entity-frameworkedmx
Jerry Nixon
Jerry Nixon

Reputation: 31803

Design Decision: Multiple EF EDMX Files

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?

Upvotes: 5

Views: 1654

Answers (2)

Danny Varod
Danny Varod

Reputation: 18069

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.

Upvotes: 1

Darren Lewis
Darren Lewis

Reputation: 8488

We've only gone as far as needing to use two separate EDMX in a single solution. This separation occurred for us with an EDMX for domain specific model entities and another for those more common across all of our solutions (Payment as an example). Logically you could say this for us was at the db schema level although that wasn't the hard rule of the separation.

Whilst we didn't have a requirement for joins across them we did need transactions. We accomplished this with a reusable UnitOfWorkContainer that would wrap the EF contexts within a TransactionScope. The contexts would be injected through DI into the container and we would only use the TransactionScope if there was more than one context held in the container.

The container itself implemented our IUnitOfWork interface so it was dead easy to plug into the existing codebase.

Upvotes: 1

Related Questions