Geek Answers Handbook

Design Solution: Multiple EF EDMX Files

If you used Entity Framework, you know that EDMX is cool. You also know that it can become HUGE and almost uncontrollable.

When it gets big, there is a temptation to create a second EDMX or a third - even one for each schema in your database (as an example).

This separation will help organize your EDMX, but it can share the context of objects in the same namespace.

In addition, individual EDMX files may create a situation where the JOIN operation in EDMX files leads to excessive redundant database communication.

But the fact remains: the more EDMX, the more difficult it is to use. The more difficult it is to ensure its correctness. Easier to break.

Do you share EDMX files? Do you have a rule of thumb about when he needs to?

+5
source share
2 answers

One example of the need to separate your EDMX would be if you have a group of objects that are used in several projects, while others are project-specific, and you are ready to refuse the presence of navigation properties between parts (and stay only with open FK) .

You can automatically combine EDMX into one if you want to save separately, but open the context for everyone and request as one. This requires that they use the same namespace.

+1
source

, EDMX . EDMX , , , (, ). , db, .

, . UnitOfWorkContainer, EF TransactionScope. DI , TransactionScope, .

IUnitOfWork, .

+1

More articles:


All Articles