继承还是不继承？想要一些专业意见[关闭]答案

【问题标题】：To inherit or not to inherit? Some professional opinions wanted [closed]继承还是不继承？想要一些专业意见[关闭]
【发布时间】：2013-07-23 01:31:43
【问题描述】：

我正在设计一个 C# ASP.Net Web 应用程序，该应用程序使用许多常见功能，而处理这些功能的正确方法似乎是通过继承。我计划创建一个基类（Person）并在 Employee 和 Vendor 等其他类中继承它，然后依次继承 Employee 和 Manager 等。这样我就不必定义常见的属性，如 FirstName、LastName、电话号码等。

问题的第二部分是这样的：如果我使用继承并使用Entity Framework的CodeFirst实体，他们会理解继承吗？数据将如何存储在表中？每个表是否都有 FirstName 和 LastName 列，或者 EF 是否足够聪明以使它们成为公共表？

我真的希望有一个真正的面向对象程序员可以帮助我解决这个问题。我得到了很多相互矛盾的信息，我需要有 EF 项目实际经验的人给我一些指导。我理解继承对吗？如果没有，我做错了什么？任何帮助表示赞赏。

谢谢，

伯特

【问题讨论】：

对于数据库选项，您提到的两个选项都是有效的，但有些人更喜欢在许多表中重复公共数据，其他人会创建一个表来保存公共数据和与之相关的其他表。

标签： c# asp.net oop inheritance code-first

【解决方案1】：

这不是一个简单的问题，但在大多数情况下，最好选择组合而不是继承。您不应该仅仅因为计算器具有显示和键盘属性就从计算器派生自动提款机。这很荒谬。
但有时继承是有意义的。问问自己，这些类是否应该具有“是”关系？正如我看到你的任务，最好让 Vendor 和 Employee 成为独立的类，它们都具有 Person 属性。并从 Employee 派生 Manager。
尽管如此，尽可能少地保持继承深度。深层层次结构很难调试和理解，尤其是在有许多方法覆盖的情况下。有关该主题的更多灵感，请查看Chad Myers blogpost。

【讨论】：

【解决方案2】：

从面向对象的角度来看，这种方法的问题在于，当一个人成为经理、员工、供应商或所有这些人时。在某些拉丁语言中，我们必须将动词形成为（ser/estar）。前者指的是存在的本质，后者指的是状态。当指的是存在的本质而不是它的状态时，最好使用 isA 进行继承。在您的情况下，我建议使用角色。一个人有很多角色。 Manager 是 Role（Manager 继承自 Role），Employee 是 Role 等。这样，您可以重用您的人员属性，并且可以添加和删除人员的角色。

【讨论】：

【解决方案3】：

第一个：听起来不错。但请确保给出了“是”关系。不要仅仅为了包含特定于地址的属性而从 Address 派生 Person - 使用 EF 复杂类型进行这种重用。

我想到一个问题：你确定Vendor 是Person 的子类型吗？

更多信息：确保您的继承权保持在“一个域”内。正如 Vinny 在另一个可能的答案中发布的那样，如果同一个人可以是 Manager 和 CustomerContact 并且都从 Person 继承，那么您会遇到问题。但是，如果经理和客户联系人不在同一个域中，最好将人员数据添加两次 - 也许同一个人希望您作为经理而不是客户联系人拥有不同的联系人数据。

第 2 部分：您可以选择 EF 生成的内容： http://www.entityframeworktutorial.net/code-first/inheritance-strategy-in-code-first.aspx

【讨论】：

好点。那不是一个很好的例子。也许是“CustomerContact”之类的。该示例只是针对问题而编造的，并不反映我将要创建的实际实体。
我还不确定你对继承有什么样的冲突信息，也许我可以添加更多关于你问题第 1 部分的具体信息。