咱们结合你的业务场景（离职员工可曾兼任多职位，在职员工仅能担任一个职位）和现有实体代码，逐个拆解这三个问题：

1. 是否需要在Position类中添加导航属性：public Employee Employee { get; set; }？ #

这完全取决于你的业务需求和查询习惯：

• 如果你的系统需要从「职位」出发，反向查询所有担任过该职位的员工（不管在职还是离职），那添加这个反向导航属性会让这类查询更便捷，代码可读性也更高。
• 如果你平时只需要从「员工」端查询对应的职位，不需要反向操作，那也可以不添加——EF Core依然能自动识别Employee和Position之间的关联关系，只是少了反向导航的便利而已。

不过从业务扩展性来看，建议加上，毕竟后续需求变动时，反向导航能省去不少重构工作。

2. 是否需要在Employee类中添加外键属性：public int PositionId { get; set; }？ #

非常建议你显式添加这个外键属性。原因有两点：

• 虽然EF Core支持「阴影外键」（框架自动生成隐式外键，无需在代码中声明），但显式外键会让你的数据操作更直接——比如你可以直接通过设置PositionId来为员工分配职位，不需要先加载完整的Position实体，效率更高。
• 显式外键能让代码逻辑更清晰，其他开发者一看就知道Employee和Position之间的关联依赖，也能避免一些隐式关联导致的奇怪问题。

3. 是否需要实现OnModelCreating方法进行关系配置？ #

首先得指出你给出的配置代码里有个小错误：应该是modelBuilder.Entity<Employee>()而不是Entity<Company>，毕竟咱们要配置的是员工和职位的关系，不是公司和员工。

回到问题本身，分两种情况：

• 如果你遵循EF Core的命名约定（比如已经添加了PositionId外键，和导航属性Position的命名匹配），框架会自动识别这是一对多关系（一个职位可以被多个员工担任），这种情况下完全不需要手动配置OnModelCreating。
• 但如果你需要自定义关系规则（比如设置级联删除行为、指定外键名称，或者结合你的业务场景添加特殊约束——比如确保在职员工（DateQuit为null）只能关联一个职位），那手动配置就很有必要了。比如要实现在职员工的职位唯一性约束，你可以在配置中添加过滤规则或者唯一索引：

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Employee>()
        .HasOne(e => e.Position)
        .WithMany(p => p.Employees) // 对应Position类中的反向导航属性
        .HasForeignKey(e => e.PositionId);

    // 示例：添加在职员工的职位唯一约束（假设后续调整实体设计，员工ID非当前主键）
    // modelBuilder.Entity<Employee>()
    //     .HasIndex(e => new { e.EmployeeId, e.DateQuit })
    //     .IsUnique()
    //     .HasFilter("[DateQuit] IS NULL");
}

另外提个小建议：从你的业务场景来看，当前的Employee类设计可能混淆了「员工实体」和「员工任职记录」的概念——如果一个员工可以有多个任职经历（包括兼任的职位），更合理的设计应该是拆分出Employee（员工基础信息）和EmployeePositionHistory（任职记录，包含Position、DateStart、DateQuit）两个实体，这样能更清晰地满足你「离职员工可兼任多职位、在职员工仅一个职位」的需求。

内容的提问来源于stack exchange，提问作者 cickness