2

有人可以告诉我将继承模型映射到 Entity Framework 5 的最佳实践方法吗？有时版本无关紧要，但在这种情况下确实如此，因为性能是关键，而 EF5 具有性能改进。

每个类型的表 (TPT) 和每个层次结构的表 (TPH) 并不是唯一的方法，但这些是我正在比较的方法。我知道由于复杂的连接，TPT 的查询性能低于 TPH。我也知道使用 TPH，表是非规范化的，这使得从长远来看很难维护。

我倾向于 TPT 和性能调整技术。当 TPH 更易于使用时，这种方法是否考虑过工程？维护的负面成本是否超过了 TPT 的负面性能和进行性能调整的努力程度？

4

2 回答 2

1

Morteza Manavi 不久前写了一系列关于此的博客文章：

  1. 使用 EF 代码优先继承：第 1 部分 – 每个层次结构的表 (TPH)。
  2. EF Code First 的继承：第 2 部分 – 每种类型的表 (TPT)。
  3. EF Code First 的继承：第 3 部分 – 每个具体类型 (TPC) 的表。

在第 3 篇文章的结尾，他总结了每种建模策略的优缺点，以及在哪些类型的情况下您希望使用其中一种而不是另一种：

在我们开始讨论之前，我想强调的是，没有一个单一的“适合所有场景的最佳策略”存在。如您所见，每种方法都有自己的优点和缺点。以下是在特定情况下确定最佳策略的一些经验法则：

  • 如果您不需要多态关联或查询，请倾向于TPC — 换句话说，如果您从不或很少查询 BillingDetails 并且您没有与 BillingDetail 基类关联的类。我建议将 TPC（仅）用于类层次结构的顶层，其中通常不需要多态性，并且将来不太可能修改基类。

  • 如果您确实需要多态关联或查询，并且子类声明的属性相对较少（特别是如果子类之间的主要区别在于它们的行为），则倾向于TPH。您的目标是尽量减少可空列的数量，并让您自己（和您的 DBA）相信非规范化模式从长远来看不会造成问题。

  • 如果您确实需要多态关联或查询，并且子类声明了许多属性（子类的主要区别在于它们所拥有的数据），那么倾向于TPT。或者，根据继承层次结构的宽度和深度以及连接与联合的可能成本，使用TPC。

默认情况下，仅针对简单问题选择 TPH。对于更复杂的情况（或者当您被数据建模者否决时，坚持认为可空性约束和规范化的重要性），您应该考虑 TPT 策略。但是到那时，问问自己，将继承改造成对象模型中的委托是否会更好（委托是一种使组合像继承一样强大以便重用的方法）。由于各种与持久性或 ORM 无关的原因，通常最好避免复杂继承。EF 充当域模型和关系模型之间的缓冲区，但这并不意味着您可以在设计类时忽略持久性问题。

于 2014-03-26T02:12:21.173 回答
0

我发现了一篇很棒的文章。基本上，仅将 TPH 用于简单的应用程序，并考虑其他替代方案用于更严重的应用程序。 这是一篇关于它以及如何对 TPT 映射进行性能调整的精彩文章。

于 2013-10-17T03:42:10.020 回答