18

每种方法的优点/缺点是什么？

我知道我在一本书或这个网站上的某处读过为什么使用表继承对于 Entity Framework 4 来说很糟糕。

例如，为什么不创建一个具有 entityId、datecreated、datemodified 的表，然后让所有其他类在实体框架中继承它呢？然后我的所有其他实体的表不需要有这些列。然后我可以让一个人类继承那个基类，然后一个特定的人继承人。

除了编写一个较小的 SQL 脚本来生成数据库之外，我不确定这样做的好处......

我看到的缺点是它使直接在 SQL 中查询/查看数据非常痛苦（所有相关信息都跨越了这么多表），我还问了我的朋友，他说：

当大多数经验不足的开发人员处理他们通过继承处理的问题时，更改应用程序代码比更改和迁移数据库数据要容易得多。我刚开始开发时也是这样做的。这在逻辑上是有道理的。但是，一旦开发了很长时间，您就会发现委托确实是最好的方法（在 soa 的情况下服务调用服务），并且单一用途的服务提供比继承更多的重用。”

这对我来说也很有意义。

所以

1）一般来说，继承与扩展的优缺点是什么
2）在我上面的具体示例中，什么更合适？
3）如果我的例子对其中一个或两个都不好，那么使用继承和使用扩展的好例子是什么？

我以前都用过，但由于我经验不足，我仍然不确定如何处理所有情况。

10票，8个收藏，过百次浏览无人能扩展？=（。

4

3 回答 3

10

我参加聚会有点晚了，但是关于 EF 中的继承，我一直有与您相同的问题，并找到了一个很好的摘要供您阅读。这是Julie Lerman 的书 Programming Entity Framework 的摘录。

阅读后，这是我对这个主题的结论：

1)一般来说，继承与扩展的优缺点是什么 - 优点实际上取决于您选择的表策略。请参阅如何选择继承策略 - MSDN 博客。但是，它们只是假设您已经决定使用继承的“专业人士”。这不是一个掉以轻心的决定。

缺点很多，但最大的缺点是无法将现有实体作为派生实体添加到数据库中。例如：我有一个继承自 Person 的 Student。有 John Smith 的 Person 记录。一段时间后，我需要约翰史密斯成为一名学生。好吧太糟糕了。那是不可能的。（至少在没有使用存储过程规避 EF 的情况下并非如此）。

2）在我上面的具体例子中，什么更合适？- 在您的示例中，您应该只将这些列（entityId、datecreated、datemodified）添加到需要它们的表中。您可以对 datecreated 和 datemodified 使用复杂类型，但除非您是一个非常严格的 DRY 人，否则这不是必需的。即使那样，它也可能是矫枉过正。原因是一旦有了实体，就永远无法将该实体添加到另一个派生表中。以后不能将 Person（它是 BaseEntity）添加为 Student。此外，编写 LINQ 查询会比需要的复杂得多。亚历克斯已经证明了这一点。

3）如果我的例子对其中一个或两个都不好，那么使用继承和使用扩展的好例子是什么？- 通常，如果您可以使您的基本类型抽象，那么继承可能对您有用。但您仍应首先考虑其他选择。如果您的基本类型将在某处直接实例化，则只需使用组合。在实际查询和插入记录时，继承变得非常麻烦。

总之，仅仅因为您可以在 EF 中进行继承并不意味着您应该这样做。如果您可以摆脱无继承设计，那么一定要这样做。

于 2011-02-26T02:22:46.797 回答
6

我已经尝试过与您描述的类似的事情，我看到的主要问题是您无法ObjectSet<T>为派生类型创建。所以你不会有ObjectSet<Person>存储库。如果您从例如 BusinessObject 实体派生所有实体，您将只能使用ObjectSet<BusinessObject>. 如果您只想查询 Person 存储库，您可以编写查询，Context.BusinessObjectSet.OfType<Person>().ToList()但我认为它不会在后台生成正确的 SQL，并且会首先获取完整的 BusinessObject 行，然后过滤掉内存中的 Person 实体。所以我想它会对性能产生巨大的影响。

于 2010-11-27T18:17:20.493 回答
3

在模型中使用继承的一个缺点是您将无法通过 WCF 数据服务 (OData) 显示模型，因为它当前不支持派生实体。

于 2010-11-29T19:01:38.313 回答