4

我对 Entity Framework 很陌生，但是我使用它的次数越多，我就越喜欢它。但现在我的热情处于危险之中，因为我正在努力解决一个已经让我把头撞到墙上的问题。

问题如下：

我正在使用 Entity Framework 5.0 和代码优先方法以及由 Table Per Hierarchy 表示的业务模型的继承。起初，我拥有所有应该被映射的实体类型，与我的 DbContext （对 TPH 和 TPT 都适用）在同一个程序集中。但是由于它们还包含依赖于其他程序集的逻辑，因此这不是一个好的方法，因为它会导致循环依赖，因为这些程序集还需要了解数据访问层，而数据访问层又必须了解实体类型它应该映射）。

我通过引入一个 CommonObjects 项目解决了这个问题，我现在保留我所有的抽象类，并将这些基类的具体后代（包含逻辑等）剥离到负责它们的特定项目中。（参见：循环依赖解决方案）

它编译了，一切似乎都符合我的想象。但现在事实证明，Entity Framework 似乎很难处理与基类不同的派生类。

在运行时，当第一次尝试访问 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 加载任何类型）。

我在这里想念什么？

提前感谢您的回答。

本

4

1 回答 1

1

编辑：这几乎不起作用而且不值得，如果您使用 CodeFirst，这根本不起作用。

我首先遇到了与代码相同的问题。我试过你的反思方法。这似乎有点不靠谱，但您可以通过内部类来欺骗 EF。

    internal class ClassToMakeEFHappy : AbstractClass {}

我刚刚在与我的 AbstractClass 定义相同的文件中创建了它，它成功了。

于 2013-12-18T03:35:29.660 回答