所以事实证明，我是最后一个在实现 TPT（每个类型的表）继承时发现 Microsoft 实体框架中存在的基本层的人。
构建了一个包含 3 个子类的原型，基表/类由 20 多列组成，子表由约 10 列组成，一切都运行良好，我继续研究应用程序的其余部分，证明了这个概念。现在是时候添加其他 20 个子类型了，OMG，我刚刚开始查看在简单选择上生成的 SQL，即使我只对访问基类上的字段感兴趣。
这一页 http://samscode.com/index.php/2010/01/the-entity-framework-v1-and-v4-deal-breaker-tpt-inheritance/对问题有精彩的描述。
有没有人使用 TPT 和 EF 投入生产？any解决方法意味着我不必：
a) 将模式转换为 TPH（这违背了我试图通过数据库设计实现的一切 - urrrgghh！）？
b) 用另一个 ORM 重写？
在我看来，我应该能够从 EF 内添加对存储过程的引用（可能使用 EFExtensions），该存储过程的 TSQL 仅选择我需要的字段，甚至使用 EF 为怪物 UNION 生成的代码SP 内的 /JOIN 会阻止每次调用时生成 SQL - 这不是我想要做的事情，但你明白了。
我发现的杀手是，当我选择链接到基表的实体列表（但我选择的实体不是子类表）时，我想按基表的 pk 进行过滤，我愿意.Include("BaseClassTableName")让我可以使用过滤x=>x.BaseClass.PK == 1并访问其他属性，它也在这里执行母 SQL 生成。
我无法使用 EF4，因为我仅限于安装了 3.5 SP1 的 .net 2.0 运行时。
有没有人有摆脱困境的经验？
这似乎有点混乱。您正在谈论 TPH，但是当您说：
在我看来，我应该能够从 EF 内添加对存储过程的引用（可能使用 EFExtensions），该存储过程的 TSQL 仅选择我需要的字段，甚至使用 EF 为怪物 UNION 生成的代码SP 内的 /JOIN 会阻止每次调用时生成 SQL - 这不是我想要做的事情，但你明白了。
嗯，这就是每个具体类的表映射（使用过程而不是表，但映射仍然是 TPC...）。 EF 支持 TPC，但设计者不支持。如果您获得了 CTP，则可以采用代码优先的方式进行操作 http://weblogs.asp.net/manavi/archive/2011/01/03/inheritance-mapping-strategies-with-entity-framework-code-first-ctp5-part-3-table-per-concrete-type-tpc-and-choosing-strategy-guidelines.aspx.
如果您限制查询，您首选的使用过程的解决方案将导致性能问题，如下所示：
var q = from c in Context.SomeChild
where c.SomeAssociation.Foo == foo
select c;
数据库优化器无法看透过程实现，因此您可以获得结果的完整扫描。
因此，在您告诉自己这将修复您的结果之前，请仔细检查该假设。
请注意，您始终可以指定自定义 SQLany映射策略ObjectContext.ExecuteStoreQuery http://msdn.microsoft.com/en-us/library/dd487208.aspx.
然而，在执行任何操作之前，请考虑一下，正如 RPM1984 指出的那样，您的设计似乎过度使用了继承。我喜欢这句话来自NHibernate 实际应用 http://neverindoubtnet.blogspot.com/2009/04/entity-framework-inheritance.html
[A]问问自己，将继承重新建模为对象模型中的委托是否会更好。由于与持久性或 ORM 无关的各种原因，通常最好避免复杂的继承。 [您的 ORM] 充当对象模型和关系模型之间的缓冲区，但这并不意味着您在设计对象模型时可以完全忽略持久性问题。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
