4

我是 Entity Framework 的新手，我正在练习 CodeFirst。我的问题是我正在创建一个模型类，我希望该类继承自其他两个类。例如，员工有个人信息，如名字、中间名、姓氏等......它还有联系信息，如地址、电话、电子邮件等......学生也有这些属性. 我之所以将这些信息分为两个不同的类别是因为另一个实体也可以有联系信息但没有个人信息，例如公司，学校，医院，仓库等......

示例代码：

public class ContactInfo
{
    public string Address { get; set; }
    public string Email { get; set; }
    public string Phone { get; set; }
}

public class PersonalInfo
{
    public string Firstname { get; set; }
    public string Middlename { get; set; }
    public string Lastname { get; set; }
}

public class Employee : // This should be inheriting from PersonalInfo and ContactInfo
{
    public int EmployeeID { get; set; }
}

public class Supplier : ContactInfo // Inheriting from ContactInfo and no PersonalInfo
{
    public int SupplierID { get; set; }
    public string Name { get; set; }
}

我想要做的是创建接口 (IPersonalInfo,IContactInfo) 以由 Employee 继承，使其看起来像这样：

public class Employee : IPersonalInfo,IContactInfo
{
    public int EmployeeID { get; set; }
}

这是一个好习惯吗？如果没有，我该如何应对这种情况？

4

2 回答 2

17

首先，听起来您混淆了继承和组合。继承的一个示例是拥有一个通用的 Person 基类，您可以从该基类继承 Employee 或 Student。组合的一个例子是一个 Employee 和一个 Supplier，每个都由一个公共 ContactInfo 对象组合，但没有公共基类。

设计实体时，实际上是在设计底层关系数据库的表结构。您可以对继承进行建模：公共基类可以由它自己的表和任何公共字段表示，并且任何专用类都可以在它们自己的表中，并具有链接到公共表的外键。这样做可能有意义，也可能没有意义 - 通过将事物分解为单独的表，您正在向查询添加另一个联接。这会降低性能。

组合也可以在关系数据库中表示，但只有当它是许多其他数据实体共享的公共组件时才真正有意义。ContactInfo 对于给定的人员/供应商几乎总是唯一的，因此将其分解为单独的表确实没有意义 - 您只是添加了一个额外的表连接，这再次会降低性能您的查询。

您应该考虑在设计中将继承/组合向上移动一层。实体（数据访问层）应该匹配关系数据库，但领域模型（即业务对象层）应该遵循面向对象的原则。

于 2013-01-26T06:13:47.473 回答
3

是的，您必须在模型中定义继承。之后，请确保您定义了一对多的关系。参考这里的链接，很好的教程。

http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/implementing-inheritance-with-the-entity-framework-in-an-asp-net-mvc-application

于 2013-01-26T01:44:58.613 回答