Using ef4 code first you can create and compile classes and dbcontext. What happens when you want to add some classes/tables and relationships in an already compiled dll of a model set?
So far the solutions I have come up with are using “partial” classes, that would be complimented later on, and the second one is writing a whole new dbcontext that includes the first one in some way or extending it, but this would mean additional db connection per module (per db context). Any ideas about this? What’s the best practice ? Also I need to be able to work with migrations.
More explicitly, a possible scenario is as follows:
A) You create a .dll with some dbContextBase class and tables(classes) inside that.
B) You create other .dlls that depend/extend dbContextBase in their own way*
C) You refference said .dlls in a project and extend them.
So basically you can have a core dbContext, then add a menu module to it, then you add a blog module to it (but it can be seen by the Menu module in order to create latest blog posts menus etc). On top of that, if you want a specific one-time feature for blog you can quickly integrate that, but also keep your blog module updateable.
As I beggin to see it the best way to do that is Nuget packages with the source code for the models (and the like) per module, instead of compiled dll.
Since there is no answer that focuses on the problem the way I put it, I am posting an answer with what seems to be the best workaround at this moment.
For full support of migrations, even custom migrations, and full support in general for code-first design, the best method is to import the source codes and compile directly.
We are using a local nuget feed in order to be able to sync multiple sub-modules freely and swiftly. This also leads to a good update experience since the migrations can easily be created or imported/integrated when needed