如何实现DbContext层次结构

Question

我想做的是操纵EF来支持访问共享数据库的插件。因此，数据库将包含主应用程序的所有表以及每个插件所需的所有表。由于应用程序对插件数据结构一无所知，所以它不能负责它们的管理。插件是唯一的责任，并创建表本身。但是，插件了解主机应用程序及其数据结构，因此理想情况下应该能够引用它们，甚至继承它们，从而生成一个可扩展但能够实现优化模式的数据库。

在EF中，这转换为包含适合主机的HostContext的DbSets。我认为，每个插件都应该有一个PluginContext，它继承自包含插件所需的DbSets的HostContext。然后，PluginContext中包含的实体类将能够引用HostContext实体和/或从这些实体继承，EF将能够解析表映射和关系。

我在用EF6。当我尝试上面的内容并试图列出我在PluginContext中包含的单个实体时，会抛出一个异常，抱怨该实体不存在。当然，没有创建匹配表。

我想要做的是得到EF的支持吗？如果是的话，我做错了什么？

Answer 1

正如我在这里提到的：EF6 Empty Model target string，我使用Rowan的示例开始了这项工作：http://romiller.com/2013/02/15/extending-and-customizing-code-first-models-part-2-of-2/

最后，我放弃了这种方法，原因有几点: 1)我无法让它工作(我不清楚为什么，但我确实怀疑这与文章撰写以来EF的差异有关)；2)我不喜欢编写手动迁移。

我最终使用了从PluginContexts继承的HostContext，正如我所希望的那样，并且能够引用甚至继承宿主实体。但这对其使用有限制：

1. 我的插件逻辑是完全独立的。我不需要主机应用程序操作或创建插件实体。因此，我不想让系统为主机实体替换任何插件实体。如果需要构造一个特定的实体子类，那么必须为此提供一个插件方法，并使用继承。
2. 迁移甚至可以构建在插件上下文上，就像正常情况一样。但是，这种迁移可以很容易地包含来自宿主上下文的迁移代码。因此，我必须记住寻找和删除这些指示。这通常是非常直截了当的，我相信这比从头开始构建等价物要少得多。
3. 如果对Host有任何更改，那么这必须反映在每个插件上下文中。基本上，这意味着每当创建新的迁移以反映主机上下文中的变化时，也必须为每个插件创建迁移，尽管迁移可能是空的(实际上并不是这样--这里的关键部分是更新最新MigrationHistory记录中的模型，以反映由于继承的主机模型而更改的插件模型)。

这种方法被用来用内部插件扩展内部应用程序，因此在Rowan的解决方案可能更适合的其他场景中，采用这种方法可能不那么容易。