3

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

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

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

谢谢,

伯特

4

3 回答 3

2

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

于 2013-07-23T19:53:50.823 回答
1

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

于 2013-07-23T19:56:29.367 回答
1

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

我想到的一个问题:您确定这Vendor是 的子类型Person吗?

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

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

于 2013-07-23T19:39:13.087 回答