DBFirst生成模型后ASP.NET Core MVC中ModelState.IsValid为false的问题

在Visual Studio 2022中创建基于.NET 7的ASP.NET Core MVC项目，采用DBFirst模式，通过Scaffold-DBContext命令生成包含Person、PersonType等实体的模型类及上下文文件，其中Person的PersonTypeId与PersonType的Id为外键关联。通过脚手架生成Person的Create控制器与视图后，提交表单时ModelState.IsValid始终为false，原因是Person的PersonType属性为null，无法将新Person保存到数据库。

困惑点 #

• (A) 在.NET Framework 4.8的Visual Studio 2019中，仅需更新数据库并生成控制器即可快速实现CRUD，为何.NET 7中操作更复杂？
• (B) 若从Bind语句移除name或PersonTypeId，验证不再检查它们，但PersonType不在Bind中却仍被验证？
• (C) 为何仅一对一关联的PersonType有此问题，而ICollection类型的属性允许为null？
• (D) FluentAPI已定义外键关系，理应知晓通过PersonTypeId即可关联PersonType，为何仍要求PersonType有值？

困惑解答 #

(A) .NET Framework与.NET 7的CRUD差异 #

.NET Framework的MVC脚手架对实体导航属性的处理更宽松，默认会跳过导航属性的验证或绑定；而.NET 7的ASP.NET Core MVC对模型验证规则更严格，脚手架生成的代码默认会让实体所有属性（包括导航属性）参与验证。另外，.NET Core更推崇关注点分离，官方推荐用ViewModel而非直接绑定实体类，这也是操作步骤看似变复杂的核心原因——不是操作变难了，而是框架引导你遵循更规范的开发模式。

(B) Bind语句与验证的逻辑边界 #

Bind管的是模型绑定阶段哪些属性会从请求里取值，而模型验证是基于实体类的元数据（比如是否非空）独立执行的。PersonType不在Bind里，只是说绑定阶段不会给它赋值，但它本身是实体类里的非空引用类型，验证阶段依然会检查它是否为null，所以会报错。而name或PersonTypeId移除Bind后不再触发验证，要么是这些属性本身允许null，要么是你没给它们加必填注解——如果是必填项，移除Bind后因为没有值，照样会触发验证错误。

(C) 一对一与ICollection属性的验证差异 #

EF Core里，ICollection<T>类型的导航属性默认被视为可空（哪怕没显式加?），因为框架会自动把空的集合初始化为空列表而非null；而一对一的导航属性（比如PersonType）会根据数据库外键是否必填，默认生成为非空引用类型，所以验证时会强制要求它不能为null。另外，集合属性在模型绑定阶段不会被自动赋值，验证逻辑也不会强制要求它有数据，自然不会出现null验证错误。

(D) FluentAPI与模型验证的职责分离 #

FluentAPI是给EF Core用的，用来定义数据库和实体之间的映射关系，告诉EF Core怎么通过外键关联导航属性；而模型验证是ASP.NET Core MVC的独立机制，只看实体类的属性类型和数据注解，不会读取EF Core的FluentAPI配置来调整验证规则。所以哪怕你定义了外键关系，MVC依然会把PersonType当成普通的非空引用类型来验证，导致ModelState.IsValid为false。

解决方案分析 #

• (1) 创建仅包含Name、PersonTypeId的ViewModel：这是最推荐的方案，完全符合MVC的设计思想。ViewModel专门适配视图需求，避免直接用实体类带来的验证、绑定问题，后续扩展功能也更灵活，不会受Scaffold-DBContext重新生成实体的影响。
• (2) 在检查ModelState.IsValid前调用ModelState.Remove("PersonType")：属于临时快速修复，能立刻消除该属性的验证错误，但后续如果实体类或验证规则变化，可能需要重复调整，不够优雅。
• (3) 将PersonType属性改为可空类型（但数据库更新时会被覆盖）：修改实体类后，只要重新执行Scaffold-DBContext就会被覆盖，每次更新数据库模型都要手动改一遍，维护成本极高，不推荐。
• (4) 为PersonType属性添加[BindNever]特性：能阻止模型绑定器处理该属性，同时避免验证触发，但同样会被Scaffold-DBContext重新生成覆盖，每次更新实体都要重新加注解，长期维护麻烦。

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