我是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; }
}
我想要做的是创建Employee继承的接口（IPersonalInfo，IContactInfo），使它看起来像这样：
public class Employee : IPersonalInfo,IContactInfo
{
public int EmployeeID { get; set; }
}
这是一个好习惯吗？如果没有，我该如何处理这种情况......
谢谢！
答案 0 :(得分：15)
首先，听起来你的遗产和构图令人困惑。继承的一个例子是拥有一个公共的Person基类，您可以从中继承Employee或Student。组合的一个示例是Employee和Supplier，每个都由一个公共的ContactInfo对象组成，但没有公共基类。
在设计实体时，您实际上是在设计底层关系数据库的表结构。您可以建模继承：公共基类可以由其自己的表和任何公共字段表示，并且任何专用类都可以在其自己的表中，其中外键链接到公共表。这样做可能有意义也可能没有意义 - 通过将内容分解为单独的表，您可以在查询中添加另一个连接。这会降低性能。
组合也可以在关系数据库中表示，但只有它是许多其他数据实体共享的公共组件才真正有意义。 ContactInfo几乎总是对于给定的人/供应商来说是独一无二的，所以将它分解成一个单独的表是没有意义的 - 你只是添加一个额外的表连接，这将再次降低性能你的疑问。
您应该考虑在设计中将继承/组合移动到一个层。实体（数据访问层）应与关系数据库匹配，但域模型（即业务对象层）应遵循面向对象的原则。
答案 1 :(得分：2)
是的，您必须在模型中定义继承。之后，请确保定义一个/多个到一个/多个关系。请参阅此处链接，好的教程。