building a generic DbContext which can exist in one project, where other projects can all have their domain models (sets of domain entities) registered
Interesting idea, but I'm not sure what you would gain by that.
For one, you'd never be able to simply type db.Customer
(or similar). It should always be genericdb.Set<Customer>()
, not knowing whether genericdb
knows about Customer
at all. (It may not have been registered).
Then, how should this registering take place? There are two ways to let a context map a class to a database model:
- Creating a
DbSet
property in aDbContext
-derived class and rely on code-first default conventions concerning table and column names, pluralization, etc. - Providing mapping configuration.
The first option defeats the purpose of a generic context class, so you'd have to register the domain classes by supplying EntityTypeConfiguration<T>
s for each class in the domain, also for classes that normally could do without. (This should be done in the context's constructor, by the way.)
A further implication would be that somewhere you'd need a component/service that knows which groups of classes belong together and is able to deliver a coherent list of configurations. So, in stead of having dedicated contexts as an organizing principle out of the box you'd have to create your own organizer.
But back to the start. Couldn't you create a DAL that contains a DbContext factory that supplies the contexts as they previously existed for your projects? You don't have to duplicate dedicated DbContext classes this way.