每种方法有哪些优点/缺点？
我知道我已经在书籍或本网站的某个地方读过为什么使用表继承对于Entity Framework 4来说很糟糕。
例如，为什么不创建一个具有entityId，datecreated，datemodified的表，然后让其他所有类继承实体框架中的那个？然后我的所有其他实体的表不需要这些列。然后我可以让一个人类继承该基类，然后一个特定的人继承人。
除了编写一个较小的SQL脚本来生成数据库之外，我不确定这有什么好处......
我看到的缺点是，它直接在SQL中查询/查看数据是一个很大的痛苦（所有相关信息在这么多表中都被打破），我也问过我的朋友说：
“对我来说最重要的事情是，我不希望我的数据库依赖于我的应用程序的当前继承结构。如果，无论出于何种原因，我想要在继承方面改变我的应用程序的设计，这没关系，因为我的数据不会依赖于我当前的系统设计。我认为数据存储只是 - 存储。数据库根据适当的数据库进行规范化设计，但继承是应用程序开发的编程选择，而不是数据存储。仅此一项就会阻止我使用它。在设计应用程序时，继承是一件非常困难的事情。更改应用程序代码要比它是更改和迁移数据库数据 当大多数经验不足的开发人员遇到问题时，他们会接受继承。我第一次开始开发的时候也是这样做的。它在逻辑上是有道理的。但是，一旦开发很长一段时间，你就会发现委托是最好的方法（服务在soa的情况下调用服务），而且单一用途的服务提供了比继承更多的重用。“
这对我来说也很有意义。
所以
1）一般来说，继承与延伸的利弊是什么？ 2）在我上面的具体例子中，哪个更合适？ 3）如果我的例子对于其中一个或两个都很糟糕，那么使用继承和使用扩展的好例子是什么？
我之前使用过两者，但由于我远没有经验丰富，我仍然不确定如何处理所有情况。
10个投票，8个收藏，超过100个观点，没有人可以扩展？ =（。答案 0 :(得分：9)
我参加派对的时间有点晚了，但是我在EF中的遗传方面遇到的问题和你的遗传问题一样，给你一个很好的总结。这是一个excerpt from Julie Lerman's book Programming Entity Framework。
阅读之后，这是我对这个主题的结论：
1）一般来说，继承与扩展的利弊是什么？ - 专业人士真正依赖于您选择的表策略。见How to choose an Inheritance Strategy - MSDN Blog。但是，假设您已经决定使用继承，它们只是“专业人士”。这不是一个轻率的决定。
缺点很多，但最大的是无法将现有实体作为派生实体添加到数据库中。例如：我有一个继承自Person的学生。 John Smith有一个Person记录。一段时间后，我需要John Smith成为一名学生。太糟糕了。那是不可能的。 （至少不能通过存储过程规避EF）。
2）在我上面的具体示例中，哪些更合适？ - 在您的示例中，您应该将这些列（entityId，datecreated，datemodified）添加到需要它们的表中。您可以使用复杂类型进行datecreated和datemodified，但除非您是一个非常严格的DRY家伙，否则这不是必需的。即便如此，它可能有点矫枉过正。原因是，一旦有了实体，就永远不能将该实体添加到另一个派生表中。一个人（这是一个BaseEntity）以后不能作为学生添加。另外，编写LINQ查询会比需要复杂得多。 Alex已经证明了这一点。
3）如果我的例子对于其中一个或两个都很糟糕，那么使用继承和使用扩展的好例子是什么？ - 通常，如果你可以使你的基类型抽象，继承< em>可能为你工作。但你应该首先考虑其他选择。如果您的基本类型将直接在某处实例化，只需使用组合。在实际查询和插入记录时，继承变得非常麻烦。
总之，仅仅因为你可以在EF中进行继承并不意味着你应该这样做。如果你能摆脱无继承设计，那么一定要做到。
答案 1 :(得分：5)
我尝试过与你描述的类似的东西，我看到的主要问题是你无法为派生类型创建ObjectSet<T>。所以你不会有ObjectSet<Person>存储库。
如果从例如BusinessObject实体派生所有实体，则只能使用ObjectSet<BusinessObject>。如果您只想查询Person存储库，您可以编写Context.BusinessObjectSet.OfType<Person>().ToList()之类的查询，但我认为它不会生成正确的SQL，并且将首先获取完整的BusinessObject行，然后过滤掉内存中的Person实体。所以我猜它会产生巨大的性能影响。
答案 2 :(得分：3)
在模型中使用继承的一个缺点是，您将无法通过WCF数据服务（OData）显示模型，因为它当前不支持派生实体。