您是说您确实有四个用户或四种类型的用户吗？我认为是后者。继承的用户如果你的类型有很多共同点，如姓名，地址等，这将是最好有一个基本类型User，和几个派生类型：OfficeManager，PropertyAdvisor，等。每个User都有零个或多个Rights，每个Right被确认为零个或多个Users：一个简单的多对多关系。数据库不能很好地处理继承的概念，您必须使用一种变通方法来实现它。实体框架知道几种实现继承的策略。这里描述了其中几个在您的情况下，最好使用“每类型表”：您将有一个Users表，并为派生类分别设置了一个Sellers表，一个Buyers表等。这些表中的每个表都具有该表的外键User。abstract class User{ public int Id {get; set;} // every User has zero or more rights (many-to-many) public virtual ICollection<Right> Rights {get; set;} ... // other properties}class Seller : User{ // inherit primary key Id from base class ... // seller properties}class Buyer : User{ // inherit primary key Id from base class ... // buyer properties}class Rights{ public int Id {get; set;} // every right is acknowledged to zero or more Users (many-to-many) public virtual ICollection<User> Users {get; set;} ... // properties that handle the rights.}您需要告诉Entity Framework，您想要为用户/买方/卖方提供单独的表格。这可以使用属性来完成。我更喜欢使用流利的API：public MyDbContext : DbContext{ // The tables: public DbSet<Right> Rights {get; set;} public DbSet<User> Users {get; set; public DbSet<Seller> Sellers {get; set;} public DbSet<Buyer> Buyers {get; set;} ... protected override void OnModelCreating(DbModelBuilder modelBuilder) { // Buyers and Sellers are in separate tables: modelBuilder.Entity<Buyer>().ToTable("Buyers"); modelBuilder.Entity<Seller>().ToTable("Sellers"); // if you want you could name the User and Right tables // but that is not needed. Entity Framework already knows // they should be in separate tables modelBuilder.Entity<User>().ToTable("Users"); }}这将导致一个Users表，一个Rights表，一个用于Users和之间的多对多关系的联结表Rights，以及每个用户派生类一个单独的表，每个表都具有该Users表的外键。您是否注意到我将User类抽象化了？这是为了防止用户DbContext添加User。我们不知道Users作为对象，我们只知道Buyers和Sellers（etc）关于表每种类型的好处是，如果你想查询的项目，所有的Users都有，就像一个名称/地址，只有一个查询表，无接缝是需要的，即使其中的一些Users是Buyers有的Sellers。另外，如果仅查询Buyer属性，则仅访问“买方”表。缺点是，如果要查询“买方”属性及其“用户”属性，则需要“用户”与“买方”表之间的联接。每种类型的表是否最适合您取决于您最常执行的查询类型。阅读所有描述的三种方法组成方法另一种方法不是使用继承，而是使用组合。这样，您的DbSet类将更好地描述您的表。其缺点是，它似乎有点怪你的DbContext的用户：Buyersdont't HAVE Users，他们Users，不是吗？与其说卖方和买方是特殊类型的用户（继承），不如 说他们有用户UserInformation（组成）。这是一对一的关系。每个人UserInformation都有零个或多个权利（一对多）。组成将导致与每个类型的表相同的表。唯一的区别是您的类更好地表示了您的表，但代价是您的类表示了您的直觉Sellers并且Buyers减少了Users的使用。class UserInformation{ public int Id {get; set;} public string FirstName {get; set;} public string MiddleName {get; set;} ... // every UserInformation has zero or more rights: (many-to-many) public virtual ICollection<Right> Rights {get; set;}}class Buyer{ public int Id {get; set;} // Every Buyer has some UserInformation using foreign key (one-to-one) public int UserInformationId {get; set;} public virtual UserInformation UserInformation {get; set;} ...}class Seller{ public int Id {get; set;} // Every Seller has some UserInformation using foreign key (one-to-one) public int UserInformationId {get; set;} public virtual UserInformation UserInformation {get; set;} ...}这将导致一个UserInformations表，一个Rights表，一个用于UserInformations和之间的多对多关系的联结表Rights，以及每个用户派生类一个单独的表，每个表都具有该Users表的外键。完全相同的表。选择是您自己的：如果要向您的用户隐藏内部数据库结构，请使用继承；如果DbContext要让您的数据库设计渗透到DbContext用户，请使用组合。