我喜欢做的是操纵EF来支持访问共享数据库的插件。因此，数据库将包含主应用程序的所有表以及每个插件所需的所有表。由于应用程序对插件数据结构一无所知，因此无法对其管理负责。插件完全负责，并自己创建表。但是，插件知道主机应用程序及其数据结构，因此理想情况下应该能够引用它们甚至从它们继承，从而产生一个可扩展但能够实现优化模式的数据库。
在EF中，这会转换为包含适合主机的DbSet的HostContext。我认为每个插件都应该有一个PluginContext，它继承自HostContext，包含插件所需的DbSet。然后，PluginContext中包含的实体类将能够引用HostContext实体，和/或从这些实体继承，EF将能够解析表映射和关系。
我正在使用EF6。当我尝试上面的内容并尝试列出我在PluginContext中包含的单个实体时，会抛出一个异常，抱怨该实体不存在。果然，没有创建匹配表。
我试图做的是EF支持的吗？如果是这样，我做错了什么？
答案 0 :(得分：0)
正如我在这里提到的：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的PluginContexts，正如我所希望的那样，并且能够引用甚至从宿主实体继承。尽管如此，它的使用受到限制：
我的插件逻辑是完全自包含的。我不需要主机应用程序来操作或创建插件实体。因此，我不是试图让系统替换宿主实体的任何插件实体。如果需要构造特定的实体子类，则必须为此提供插件方法，并且将使用继承性层次结构。
根据正常情况，甚至可以在插件上下文中构建迁移。但是，该迁移可能很容易包含来自Host Context的迁移代码。所以我必须记住寻找并删除这些说明。这通常非常简单，我认为比从头开始构建等效的工作要少得多。
如果主机上下文有任何更改，则必须在每个插件上下文中反映出来。基本上，这意味着无论何时创建新的迁移以反映主机上下文中的更改，都必须为每个插件创建迁移，即使该迁移可能为空（它不是真的 - 这里的关键部分是更新在最新的MigrationHistory记录中建模，以反映由于继承的主机模型而更改的插件模型。）
这种方法被用于扩展内部应用程序的内部应用程序，因此在Rowan的解决方案可能更适合的其他场景中可能不那么容易采用。