I have a web app (ERP variety) with 90 tables and counting. I am using Entity Framework 6 and the database first approach. I'd like to split up the DBContext and create multiple DBContexts. But how do you handle tables that would be common to both? i.e. would it make sense to have a common context and inherit from it? Can you even do that?
FinancialsContext : CommonContext
- InvoiceHeader
- InvoiceDetail
OrderManagementContext : CommonContext
- OrderHeader
- OrderDetail
CommonContext
- User
- Item
Will this allow you to directly access related table properties that are related via the CommonContext...like: OrderHeader.User.FirstName
If this won't work, any other suggestions?
UPDATE 1 - inheritance does not work:
I tried this approach and found that the related entities are established from the FinancialsContext to the CommonContext. i.e you can't access the first name of the user that modified the OrderHeader like: OrderHeader.User.FirstName
So I guess you need to just duplicate the Common business objects in each domain's context like so:
FinancialsContext
- InvoiceHeader
- InvoiceDetail
- User
- Item
OrderManagementContext
- OrderHeader
- OrderDetail
- User
- Item
Am I missing something?
UPDATE 2 So I guess having the same table in multiple contexts doesn't work either...at least not without renaming them so their names are unique, which I don't want to do.
Schema specified is not valid. Errors:
The mapping of CLR type to EDM type is ambiguous because multiple CLR types match the EDM type 'CustomerContact'. Previously found CLR type 'OTIS.Domain.Financials.CustomerContact', newly found CLR type 'OTIS.Domain.InventoryMgmt.CustomerContact'.
The mapping of CLR type to EDM type is ambiguous because multiple CLR types match the EDM type 'OrderDetail'. Previously found CLR type 'OTIS.Domain.Financials.OrderDetail', newly found CLR type 'OTIS.Domain.InventoryMgmt.OrderDetail'.
I found this SO answer, and for me, it seems that I will forgo separate dbcontexts unless the tables are truly only going to be used in one context only (like some of my system admin related tables).
I have not seen any true stats on performance implications for having many tables in a dbcontext and having to do unnatural things like querying from 2 contexts then joining the results in memory, is not worth the hassle and trading off the performance of smaller, but multiple contexts, with then having to do performance degrading things like 2 separate queries and joining them.
