我想做的是操纵EF以支持访问共享数据库的插件。因此，数据库将包含主应用程序的所有表以及每个插件所需的所有表。由于应用程序对插件数据结构一无所知，因此无法对其进行管理。插件全权负责，并自行创建表。但是，插件知道主机应用程序及其数据结构，因此理想情况下应该能够引用它们甚至从它们继承，从而导致数据库可扩展但能够实现优化的模式。
在EF中，这转换为包含适用于主机的DbSet的HostContext。我认为，每个插件都应具有一个从HostContext继承的PluginContext，该上下文包含插件所需的DbSet。然后，包含在PluginContext中的实体类将能够引用HostContext实体，和/或从这些实体继承，并且EF将能够解析表映射和关系。
我正在使用EF6。当我尝试上述操作并尝试列出包含在PluginContext中的单个实体时，抛出异常，抱怨该实体不存在。果然没有创建匹配表。
我正在尝试得到EF支持的内容吗？如果是这样，我在做什么错？
正如我在这里提到的：EF6 Empty Model target string我从此处使用罗文·米勒（Rowan Miller）的示例开始了这项工作：http://romiller.com/2013/02/15/extending-and-customizing-code-first-models-part-2-of-2/
最后，出于以下几个原因，我放弃了该方法：1）我无法使其正常工作（我不记得确切的原因，但我确实怀疑自撰写本文以来，它与EF的差异有关）和2）我不喜欢需要编写手动迁移。
我最终得到了如我所愿的那样从HostContext继承的PluginContext，并且能够引用甚至从主机实体继承。但这有其使用限制：
我的插件逻辑完全独立。我不需要主机应用程序来操纵或创建插件实体。因此，我并不是想让系统将任何插件实体替换为主机实体。如果需要构造特定的实体子类，则必须为此提供一个插件方法，并且将使用继承层次。
甚至可以按照常规在插件上下文中构建迁移。但是，该迁移可能很容易包含来自主机上下文的迁移代码。因此，我必须记住要查找并删除这些说明。这通常非常简单明了，并且我相信比从头开始构建等效项要花费更少的精力。
如果主机上下文有任何更改，则必须在每个插件上下文中反映出来。基本上，这意味着每当创建新迁移以反映Host Context中的更改时，也必须为每个插件创建迁移，即使该迁移可能为空（这不是真的-此处的关键部分是更新Model中的Model最新的MigrationHistory记录，以反映由于继承了主机模型而已更改的插件模型）。
[此方法正被用于扩展具有内部插件的内部应用程序，因此在罗恩的解决方案可能更适合的其他情况下可能不那么容易采用。