ASP.NET MVC Core集成Identity：Person模型属性迁移决策咨询

不用全部迁移，得根据属性和身份认证、业务逻辑的关联度来划分：

建议迁移到ApplicationUser的属性 #

• Age：属于用户基础身份信息，和账号绑定紧密，登录后通常会频繁用到这类基础数据，放在ApplicationUser里能直接通过Identity框架获取，不用额外做关联查询，效率更高。
• Gender：同样是用户基础身份标识，和账号强关联，迁移后可以和账号注册、个人信息修改等流程统一处理，简化逻辑。

不建议迁移到ApplicationUser的属性 #

• Hobbies：属于用户的业务扩展信息，和身份认证核心逻辑无关，而且是关联Hobby实体的集合类型。如果塞进ApplicationUser，会让Identity的用户模型变得臃肿，违背单一职责原则，后续维护也麻烦。

推荐的两种实现方案 #

方案1：保留Person模型，与ApplicationUser建立关联 #

给Person模型加外键关联ApplicationUser，让两者职责分离：

class Person {
    public int Id { get; set; }
    public int Age { get; set; }
    public string Gender { get; set; }
    public List<Hobby> Hobbies { get; set; }
    
    // 关联Identity用户
    public string ApplicationUserId { get; set; }
    public ApplicationUser ApplicationUser { get; set; }
}

这种方式下，ApplicationUser负责账号登录、权限管理等身份相关逻辑，Person负责业务领域的用户信息，边界清晰。

方案2：合并基础属性，拆分业务属性 #

如果觉得Age、Gender和账号绑定过于紧密，也可以把这两个属性直接移到ApplicationUser里，只让Person保留Hobbies这类业务扩展属性，再让ApplicationUser关联Person：

class ApplicationUser : IdentityUser {
    public int Age { get; set; }
    public string Gender { get; set; }
    
    // 关联业务扩展的Person信息
    public Person Person { get; set; }
}

class Person {
    public int Id { get; set; }
    public List<Hobby> Hobbies { get; set; }
    
    public string ApplicationUserId { get; set; }
    public ApplicationUser ApplicationUser { get; set; }
}

核心判断原则 #

• 单一职责优先：ApplicationUser只负责身份认证、授权的核心功能，别把无关的业务属性塞进去。
• 看使用频率：经常和账号信息一起查询的基础属性，适合放ApplicationUser；不常用的业务扩展属性，单独放在业务模型里。

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