Inheritance EF4.1-性能问题-多个子类

我最近开始使用EF4.1代码，一切都很好（喜欢MVC），但现在开始遇到主要的性能问题

我有大约20个简单的POCO类，它们是从一个基类派生的，使用每个类型的表EF继承映射：

EF为我提供了一个干净的表层次结构。但是，如果我现在从数据库加载一个对象，就像这样，可能需要几秒钟：

DerivedClass derivedObject = context.Set<DerivedClass>().Find(id);

DerivedClass-derivedObject=context.Set（）.Find（id）；

我已经检查了是否启用了延迟加载，并使用SQL Profiler将问题缩小到EF创建的SQL查询中，以检索对象，这与此处的查询结构类似，但要大得多：

由于我有20个子类是从同一个基类派生的，EF正在对所有20个表进行SQL联合和联接（尽管我只需要两个表中的数据-用于子类和基类），创建一个包含大约100列的结果表，即派生+基类中的属性/列总数。SQL查询的文本长度超过300KB，在本地机器上的SQLServerManagementStudio中执行查询需要大约3秒钟的时间来重设一行数据，这是一个致命的问题

我只是刚刚诊断出这个问题，所以如果有任何关于重新构造代码以修复的反馈，我将不胜感激。我目前的想法是：

• 通过使用接口而不是基类来展平对象结构，将基类功能复制到所有子类，并对表层次结构进行非规范化（非规范化不是一个主要问题，从db的角度来看可能更有效，但复制基类功能将是痛苦的）

• 为所有数据检索创建存储过程，包括延迟加载调用（痛苦但可能很容易错过调用）

救命啊！我是牺牲OO还是EF

如果有人知道如何简化EF创建的SQL查询，而不必重新构造我的类结构，那就更好了。

这是

---

如果您迫不及待地想要修复，一个可能的解决方法是使用TPH映射。

太棒了-感谢Craig-没有看到这个CTP。枚举也是-正是我想要的。关于这部电影的官方发布日期有什么估计吗？@Sydney:这是第一部CTP。如果我们回顾一下EFv4.1，从第一个CTP到上线许可证的时间要远远超过一年。希望这个版本会有更短的周期，但我仍然希望在6-12个月之间的事情，直到上线许可证。谢谢大家。我安装了CTP，它对我上面给出的示例进行了改进，但在其他操作中仍然非常慢，例如：context.Entry（derivedObject.Reload（）；文章提到TPC映射也有问题。它们和TPT一样糟糕吗？从db的角度来看，TPH看起来非常“浪费”，在派生类上有很多不同的属性。如果TPC克服了性能问题，我很乐意这样做，但仍然会导致大量重写，所以在我重组之前需要了解其影响