ASP.NET MVC中HttpPost场景下如何处理数据库为标识列的ViewModel的Id属性

这类场景的标准处理方案主要有以下3种，你可以根据项目复杂度选择： #

方案1：拆分视图模型（最符合单一职责原则的标准方案） #

将创建场景和查询/编辑场景的ViewModel拆分为不同的类，职责完全隔离：

• 创建场景用CreatePaycheckTypeViewModel，仅保留创建时需要传入的字段：

public class CreatePaycheckTypeViewModel
{
    public string Type { get; set; }
    public int CustomSortOrder { get; set; }
}

• 列表展示、编辑场景复用你现有的PaycheckTypeViewModel，保留Id字段用于渲染和更新操作。
  这种方案没有多余字段、不存在序列化歧义，是中大型项目的首选规范。

方案2：配置条件序列化忽略（不想拆分模型时的轻量方案） #

不用加全局的[JsonIgnore]，改为配置仅当Id为默认值时序列化忽略：

• 如果你用的是System.Text.Json（ASP.NET Core默认序列化器）：给Id字段加[JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingDefault)]特性，int类型默认值是0，创建操作时Id=0就不会被序列化到请求中，编辑时Id有非0值会正常序列化，完全满足你既要展示用Id、又要创建时不传输Id的需求。
• 如果你用的是Newtonsoft.Json：给Id字段加[JsonProperty(NullValueHandling = NullValueHandling.Ignore, DefaultValueHandling = DefaultValueHandling.Ignore)]特性即可。

方案3：调用API时手动构造匿名对象（临时适配的灵活方案） #

不需要修改模型定义，在调用Post接口时只传需要的字段：

var responseMessage = await client.PostAsJsonAsync("paycheck-type", new 
{
    paycheckType.Type, 
    paycheckType.CustomSortOrder 
});

这种方案适合临时适配，不需要改动现有模型结构，小项目快速迭代时用很方便。

你现在直接传带Id=0的请求虽然不会报错，但确实不属于最佳实践：一方面传输了无意义的冗余字段，另一方面如果后续API调整了逻辑，增加了Id字段非0校验、或者错误把传入的Id当做有效值处理，会引发隐性问题。

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