Kendo Grid保存时数据源模型异常及Core2 API交互问题排查

看起来你在推进公司项目的Kendo Grid集成时遇到了几个典型的前后端数据交互问题，我帮你拆解下核心痛点，然后一步步给出排查和解决思路：

核心问题复盘 #

你当前遇到的问题可以归纳为三点：

• Grid保存时自动生成了多余的adName字段
• 核心字段projectCoder未正确赋值，关联属性projectCoderNavigation为空
• POST请求到达Core API后模型直接为空，触发500内部错误
• 尝试用parameterMap手动赋值projectCoder，但多余字段和空属性问题依然存在

一步步排查解决 #

1. 先锁死Grid的字段范围，杜绝自动生成多余属性 #

Kendo Grid在默认编辑模式下，会自动读取数据源中的所有属性（包括关联实体的嵌套属性，比如projectCoderNavigation.adName），并将其加入提交数据。这大概率是adName字段莫名出现的原因。

解决方法：

• 显式定义Grid的columns列表，只保留你需要提交的业务字段，不要包含关联实体的属性：

columns: [
  { field: "projectId", title: "项目ID", editable: false },
  { field: "projectCoder", title: "项目编码", validation: { required: true } },
  { field: "projectName", title: "项目名称" },
  // 只保留你需要的字段，删除所有关联实体相关列
]

• 同时在schema.model中严格定义模型结构，排除不需要的字段：

schema: {
  model: {
    id: "projectId",
    fields: {
      projectId: { editable: false, nullable: true },
      projectCoder: { type: "string", validation: { required: true } },
      projectName: { type: "string" }
      // 绝对不要定义projectCoderNavigation这类关联对象字段
    }
  }
}

2. 修正parameterMap的转换逻辑，精准匹配API模型 #

你尝试用parameterMap处理数据，但可能没有做到严格过滤+结构对齐。这个函数的核心作用就是把Grid的数据源数据，转换成完全符合API接收模型的JSON结构，同时剔除多余字段。

正确示例：

transport: {
  create: {
    url: "/api/Project/Create",
    type: "POST",
    contentType: "application/json", // 必须指定JSON格式
    headers: { "RequestVerificationToken": $('input[name="__RequestVerificationToken"]').val() } // 如果用了防CSRF，记得加这个
  },
  parameterMap: function(data, operation) {
    // 只在新增/更新时处理数据
    if (operation === "create" || operation === "update") {
      // 只保留API模型需要的字段，完全对齐后端DTO
      return kendo.stringify({
        ProjectCoder: data.projectCoder, // 注意大小写，和后端模型属性名一致
        ProjectName: data.projectName
        // 其他需要的字段逐一列出，不要包含多余属性
      });
    }
    return data;
  }
}

这里要特别注意：前端传递的字段名必须和ASP.NET Core模型的属性名完全匹配（包括大小写，如果后端没配置驼峰映射的话）。

3. 排查API端的模型绑定配置 #

POST请求到达API后模型为空，90%的原因是Content-Type不匹配或者模型绑定配置错误：

• 确保API的Action方法加上[FromBody]特性，明确从请求体读取JSON：

[HttpPost]
public async Task<IActionResult> Create([FromBody] ProjectCreateDto model)
{
  if (!ModelState.IsValid)
  {
    return BadRequest(ModelState);
  }
  // 业务逻辑...
}

• 检查后端模型的属性是否和前端传递的字段一致，比如如果后端用了[JsonPropertyName("projectCoder")]特性，前端就要用小写的projectCoder，否则绑定会失败。
• 不要在API模型中定义ProjectCoderNavigation这类关联实体属性，除非你明确需要传递关联数据，否则会导致模型绑定失败。

4. 打印请求日志，定位实际传递的数据 #

如果以上步骤都没解决问题，最直接的方法就是看前端实际发了什么数据。你可以在API中加一个简单的中间件，打印请求体内容：

public class RequestLoggerMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<RequestLoggerMiddleware> _logger;

    public RequestLoggerMiddleware(RequestDelegate next, ILogger<RequestLoggerMiddleware> logger)
    {
        _next = next;
        _logger = logger;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        context.Request.EnableBuffering();
        var requestBody = await new StreamReader(context.Request.Body).ReadToEndAsync();
        _logger.LogInformation("Received Request Body: {RequestBody}", requestBody);
        context.Request.Body.Position = 0; // 重置流位置，避免后续中间件无法读取
        await _next(context);
    }
}

然后在Program.cs中注册中间件：

app.UseMiddleware<RequestLoggerMiddleware>();

查看日志里的请求体，对比你的API模型，就能一眼看出哪些字段不匹配、哪些多余字段被传递了。

5. 禁用Kendo的自动数据扩展 #

如果你的Grid数据源来自API返回的包含关联实体的数据，Kendo会自动保留这些嵌套属性。可以在schema.parse中手动清理：

schema: {
  parse: function(response) {
    // 遍历数据，删除不需要的关联属性
    response.data.forEach(item => {
      delete item.projectCoderNavigation;
      delete item.adName;
    });
    return response;
  },
  // ...其他配置
}

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