ASP.NET MVC POST/PUT对象存储最佳实践 登录用户项目创建方案

两种示例方案的规范对比 #

第二种使用独立ViewModel接收表单输入的方案更符合ASP.NET MVC设计规范，第一种直接绑定数据库实体的方案是明确的反模式，核心原因如下：

• 直接绑定Project实体的方案存在固有安全风险：即使使用[Bind]特性做字段白名单，也无法彻底避免批量赋值（Mass Assignment）漏洞——一旦后续迭代给Project实体加了敏感字段（比如OwnerId、IsDeleted这类），只要维护时漏改[Bind]的白名单，恶意用户就可以通过构造表单请求篡改这些服务端才应该控制的字段。
• 直接绑定实体会让分层边界混乱：数据库实体的职责是和表结构映射，会携带导航属性、数据库配置相关的特性，和视图层需要的输入/展示逻辑完全无关，长期维护会导致实体上堆大量和持久化无关的校验、展示特性，代码复杂度会快速升高。
• 第一种示例代码本身就存在类型错误：将int类型的Session.UserId赋值给User类型的Owner导航属性，运行时会直接抛出类型不匹配异常，且ModelState校验的逻辑顺序也不合理。

第二种方案通过独立的输入模型隔离了视图层和持久化层，表单允许提交的字段完全由ViewModel定义，从机制上避免了过度提交问题，是MVC模式推荐的做法。 #

该场景的更优实现方案 #

原两个示例都存在不少细节错误，符合生产规范的实现需要注意以下几点：

• 所有权限、归属类的字段（比如这里的OwnerId）绝对不能从前端请求中获取，必须从服务端的身份认证上下文取当前登录用户ID，不要用自定义Session存用户身份，直接使用ASP.NET内置认证体系提供的User对象读取用户声明即可。
• ViewModel必须使用自动属性（原示例用public字段会导致模型绑定器无法正常绑定数据），且只定义前端需要提交的字段，在ViewModel上加对应输入校验规则，不要把数据库实体上的校验规则直接复用给输入层。
• 不要用[Bind]特性做字段过滤，维护成本和出错概率极高。
• 数据操作使用EF Core提供的异步方法提升接口吞吐量，加[ValidateAntiForgeryToken]特性防御CSRF攻击。

正确代码示例 #

首先修正ViewModel定义：

// 专门用于接收创建项目表单输入的ViewModel
public class ProjectCreateViewModel
{
    [Required(ErrorMessage = "项目名称不能为空")]
    [MaxLength(100, ErrorMessage = "项目名称长度不能超过100个字符")]
    public string Name { get; set; } = string.Empty;
}

控制器实现：

public class ProjectController : Controller
{
    private readonly ApplicationDbContext _context;

    public ProjectController(ApplicationDbContext context)
    {
        _context = context;
    }

    // GET: 渲染空白创建表单
    public IActionResult Create()
    {
        return View();
    }

    // POST: 处理表单提交
    [HttpPost]
    [ValidateAntiForgeryToken]
    public async Task<IActionResult> Create(ProjectCreateViewModel model)
    {
        // 先校验前端传入的字段是否合法
        if (!ModelState.IsValid)
        {
            return View(model);
        }

        // 从内置身份认证上下文获取当前登录用户ID，完全由服务端控制，无法被前端篡改
        var currentUserId = int.Parse(User.FindFirstValue(ClaimTypes.NameIdentifier));

        // 手动映射生成数据库实体，所有服务端控制的字段在这里明确赋值
        var project = new Project
        {
            Name = model.Name,
            OwnerId = currentUserId
            // 其他服务端生成字段比如创建时间、默认状态等都在这里赋值
        };

        _context.Projects.Add(project);
        await _context.SaveChangesAsync();

        return RedirectToAction(nameof(Index));
    }
}

本例中的DTO是否属于ViewModel范畴 #

属于。
在ASP.NET MVC的约定里，DTO（数据传输对象）是跨层传递纯数据结构的统称，本身不承载业务逻辑；而ViewModel是专门用于控制器和视图层之间传递数据的一类特殊DTO，职责是承载视图渲染所需数据、接收用户表单输入，和持久化层的数据库实体完全解耦。
示例中的ProjectModelView是专门用来接收创建项目表单输入的结构，完全符合ViewModel的定义，只是原代码存在写法错误（用public字段而非属性、缺失输入校验），但范畴上是标准的输入型ViewModel。 #

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