entity framework - How to implement DbContext hiearchy -
what i'd manipulate ef support plugins access shared database. database contain of tables main application plus of tables required each plugin. application doesn't know plugin data structures, cannot responsible management. plugins solely responsible, , create tables themselves. however, plugins know host application , data structures, ideally should able reference them , inherit them, resulting in database extensible yet able implement optimized patterns.
in ef, translates hostcontext contains dbsets appropriate host. each plugin, thought, should have plugincontext inherits hostcontext contains dbsets needed plugin. entity classes included in plugincontext able reference hostcontext entities, and/or inherit entities, , ef able resolve table mapping , relationships.
i'm using ef6. when attempt above , try list single entity i've included in plugincontext, exception thrown complaining entity doesn't exist. sure enough, no matching table has been created.
is i'm attempting supported ef? if so, doing wrong?
as mentioned here: ef6 empty model target string began effort using rowan miller's example here: http://romiller.com/2013/02/15/extending-and-customizing-code-first-models-part-2-of-2/
in end, abandoned approach, few reasons: 1) couldn't work (i can't remember why suspect related differences in ef since article written), , 2) didn't need write manual migrations.
i ended plugincontexts inherit hostcontext, had hoped, , able reference , inherit host entities. has restrictions in use though:
my plugin logic self contained. have no need host application manipulate or create plugin entities. therefore, not trying system subsitute plugin entities host entities. if construction of particular entity subclass required, plugin method must provided , inheritence hiearchy utilized.
migrations can built on plugin context per normal. however, migration may include migration code host context. have remember , remove these instructions. typically straightforward , believe less effort building equivalent scratch.
if there change host context must reflected in every plugin context. basically, means anytime new migration created reflect changes in host context, migrations must created each plugin well, though migration may empty (it isn't - critical part here updating model in latest migrationhistory record reflect plugin model has been changed because of inherited host model).
this approach being used extend in-house application in-house plugins, , may not easy adopt in other scenarios rowan's solution better suited.
Comments
Post a Comment