我对Entity Framework很陌生，但我使用它越多，我就越喜欢它。但是现在我的热情处于危险之中，因为我正在努力解决一个已经让我砸到墙上的问题。
问题如下：
我正在使用Entity Framework 5.0，它采用代码优先方法，并继承了Table Per Hierarchy表示的业务模型。起初，我将所有应该映射的实体类型放在与我的DbContext相同的程序集中（对于TPH和TPT都可以正常工作）。但由于它们还包含依赖于其他程序集的逻辑，因此它被认为是没有好方法，因为它导致循环依赖，因为这些程序集还需要具备数据访问层的知识，而数据访问层又需要了解实体类型它应该映射）。
我通过引入一个CommonObjects项目来解决这个问题，我现在保留了所有抽象类，并将这些基类的具体后代（包含逻辑等）剥离到特定项目中，这些项目负责它们。 （见：Circular Dependency Solution）
它编译了，一切似乎都符合我的想象。 但现在事实证明，实体框架似乎很难与衍生集团在基础类不同的集合中。
在运行时，第一次尝试访问DbContext时，编译器抛出了一个InvalidOperationException：
抽象类型'Foo.Bar.AbstractClass'没有映射的后代 所以无法映射。从中删除'Foo.Bar.AbstractClass' 模型或添加一个或多个派生类型 'Foo.Bar.AbstractClass'到模型。
所以EF显然无法找到后代，因为它只知道基类（在CommonObjects项目中），但后代在不同的程序集中。
DbSet<AbstractClass> AbstractClasses { get; set; }
根据这个问题： Entity Framework Code First and Multiple Assemblies 我尝试将以下代码添加到我的派生DbContext的构造函数中：
((IObjectContextAdapter)this).ObjectContext.MetadataWorkspace.LoadFromAssembly(
Assembly.Load("Foo1"));
但这对我不起作用。在调试和观察MetadataWorkspace时，方法“LoadFromAssembly”显然对MetadataWorkspace及其项目没有任何影响（没有类型从程序集Foo1加载）。
我在这里缺少什么？
提前感谢您的回答。
本
答案 0 :(得分：1)
编辑：这只是不起作用而且不值得，如果你使用的是CodeFirst，它根本不起作用。
我首先遇到了与代码相同的问题。我试过你的反思方法。这看起来有点不稳定，但你可以通过设置内部类来欺骗EF。
internal class ClassToMakeEFHappy : AbstractClass {}
我刚刚在与AbstractClass定义相同的文件中创建了它，并且它完成了这个技巧。