0

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

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

我正在使用 EF6。当我尝试上述方法并尝试列出我已包含在 PluginContext 中的单个实体时，会引发异常，抱怨该实体不存在。果然，没有创建匹配表。

EF 支持我尝试做的事情吗？如果是这样，我做错了什么？

4

1 回答 1

0

As I mentioned here: EF6 Empty Model target string I began this effort using Rowan Miller's example here: http://romiller.com/2013/02/15/extending-and-customizing-code-first-models-part-2-of-2/

In the end, I abandoned that approach, for a few reasons: 1) I couldn't get it to work (I can't remember exactly why but I do suspect it was related to differences in EF since the article was written), and 2) I didn't like the need to write manual migrations.

I ended up with PluginContexts that inherit from HostContext, as I had hoped, and am able to reference and even inherit from host entities. This has restrictions in its use though:

  1. My plugin logic is completely self contained. I have no need for the host application to manipulate or create plugin entities. Therefore, I am not trying to get the system to subsitute any plugin entities for host entities. If construction of a particular entity subclass is required, then a plugin method must be provided for that and an inheritence hiearchy will be utilized.

  2. Migrations can be built even on the plugin context as per normal. However, that migration may easily include migration code from the Host Context. So I have to remember to look for and remove these instructions. This is typically very straightforward and I believe is much less effort than building the equivalent from scratch.

  3. If there is any change to the Host Context then this must be reflected in every Plugin Context. Basically, this means anytime a new migration is created to reflect changes in Host Context, migrations must be created for each plugin as well, even though that migration may be empty (it isn't really - the critical part here is updating the Model in the latest MigrationHistory record to reflect the Plugin model that has been changed because of the inherited Host model).

This approach is being used to extend an in-house application with in-house plugins, and so may not be as easy to adopt in other scenarios which Rowan's solution is probably better suited.

于 2013-09-25T19:36:43.310 回答