Are there non-inheritance-chain-mess ways to make modular libraries that rely on Entity Framework based on one DB context in the using project?
I am developing some modular libraries that contain common APIs, data, and functionality. One of the core assumptions to these libraries is you would use which you want to compose your project, but then you could extend as necessary with custom code if desired. Especially on the entities that would come with those libraries/modules. Now a great example is the Microsoft Identity Framework. And in that, if you want to use it, you add the libraries, have your custom DBContext inherit from the IdentityDbContext and you're all set. You can access the identity APIs and your custom will have everything needed to control users and access. Great. But now what if you have multiple that you can mix and mix via these libraries? Making an inheritance chain of DbContexts, one for each module you use, sounds like awful design. Is there any way you could somehow supply the custom DbContext when registering the library in app start up and somehow have your library use that while not running into a scenario where errors would only be run time. Because I could maybe imagine a reflection scenario and compose it, but that also sounds like bad design because it would only work at run time and you couldn't use it during programming. I would like to basically emulate the Identity package usage in terms of implementation and customization, except with the ability that it could be done with multiple in the same project.
I am developing some modular libraries that contain common APIs, data, and functionality. One of the core assumptions to these libraries is you would use which you want to compose your project, but then you could extend as necessary with custom code if desired. Especially on the entities that would come with those libraries/modules.
Now a great example is the Microsoft Identity Framework. And in that, if you want to use it, you add the libraries, have your custom DBContext inherit from the IdentityDbContext and you're all set. You can access the identity APIs and your custom will have everything needed to control users and access. Great. But now what if you have multiple that you can mix and mix via these libraries? Making an inheritance chain of DbContexts, one for each module you use, sounds like awful design.
Is there any way you could somehow supply the custom DbContext when registering the library in app start up and somehow have your library use that while not running into a scenario where errors would only be run time. Because I could maybe imagine a reflection scenario and compose it, but that also sounds like bad design because it would only work at run time and you couldn't use it during programming.
I would like to basically emulate the Identity package usage in terms of implementation and customization, except with the ability that it could be done with multiple in the same project.
