谁能告诉我将继承模型映射到 Entity Framework 5 的最佳实践方法？有时版本无关紧要，但在这种情况下确实如此，因为性能是关键，而 EF5 具有性能改进。
每个类型的表 (TPT) 和每个层次结构的表 (TPH) 并不是唯一的方法，但这些是我正在比较的方法。我知道由于复杂的连接，TPT 的查询性能低于 TPH。我也知道使用 TPH，表是非规范化的，从长远来看很难维护。
我倾向于 TPT 和性能调整技术。当 TPH 更易于使用时，这种方法是否考虑过工程？维护的负面成本是否超过了 TPT 的负面性能和进行性能调整的努力程度？
【问题讨论】：
标签： sql .net entity-framework orm ado.net
Morteza Manavi 不久前写了一系列关于此的博客文章：
在第 3 篇文章的最后，他总结了每种建模策略的优缺点，以及在哪些类型的情况下您希望使用其中一种而不是另一种：
在我们开始讨论之前，我想强调的是，不存在单一的“适合所有场景的最佳策略”。如您所见，每种方法都有自己的优点和缺点。以下是一些经验法则，用于确定特定场景中的最佳策略：
如果您不需要多态关联或查询，则倾向于 TPC - 换句话说，如果您从不或很少查询 BillingDetails 并且您没有与BillingDetail 基类。我建议将 TPC（仅）用于类层次结构的顶层，通常不需要多态性，并且将来不太可能修改基类。
如果您确实需要多态关联或查询，并且子类声明的属性相对较少（特别是如果子类之间的主要区别在于它们的行为），则倾向于 TPH。您的目标是尽量减少可空列的数量，并让您自己（和您的 DBA）相信，从长远来看，非规范化架构不会造成问题。
如果您确实需要多态关联或查询，并且子类声明了许多属性（子类的主要区别在于它们所拥有的数据），请倾向于 TPT。或者，根据继承层次结构的宽度和深度以及连接与联合的可能成本，使用 TPC。
默认情况下，仅针对简单问题选择 TPH。对于更复杂的情况（或者当您被数据建模者否决时，坚持认为可空性约束和规范化的重要性），您应该考虑 TPT 策略。但是到那时，问问自己，将继承改造成对象模型中的委托是否会更好（委托是一种使组合像继承一样强大以便重用的方法）。由于各种与持久性或 ORM 无关的原因，通常最好避免复杂继承。 EF 充当域模型和关系模型之间的缓冲区，但这并不意味着您可以在设计类时忽略持久性问题。
【讨论】：
我发现了一篇很棒的文章。基本上，仅将 TPH 用于简单的应用程序，并考虑其他替代方案用于更严重的应用程序。 Here is a great article about it 以及如何调整 TPT 映射的性能。
【讨论】：