验证应贯穿输入层、业务逻辑层和数据访问层。1. 输入层用数据注解（如[required]、[emailaddress]）结合modelstate.isvalid拦截无效请求；2. 服务层检查业务规则（如邮箱唯一性、状态合法性）并抛出相应异常；3. 数据库通过主键、唯一约束、check等确保数据完整性，ef core可在onmodelcreating中配置。各层协同防御，保障数据合法安全。
在C#中实现数据库数据的验证，核心目标是确保进入数据库的数据合法、完整、安全。验证通常不只在一个阶段完成，而是贯穿整个应用流程，尤其集中在输入层和业务逻辑层，数据库本身也可设置约束作为最后一道防线。
1. 输入层验证（前端与API入口）
这是第一道防线，尽早发现错误，提升用户体验。
• 使用数据注解（Data Annotations）对模型进行标记，常用于ASP.NET Core Web API或MVC：
public class User
{
[Required(ErrorMessage = "姓名不能为空")]
[StringLength(50, MinimumLength = 2, ErrorMessage = "姓名长度必须在2-50之间")]
public string Name { get; set; }
[EmailAddress(ErrorMessage = "邮箱格式不正确")]
public string Email { get; set; }
[Range(18, 100, ErrorMessage = "年龄必须在18到100之间")]
public int Age { get; set; }
}
• 在控制器中通过 ModelState.IsValid 判断是否通过验证：
[HttpPost]
public IActionResult CreateUser(User user)
{
if (!ModelState.IsValid)
{
return BadRequest(ModelState);
}
// 继续处理
}
2. 业务逻辑层验证（服务层）
输入验证不能完全依赖属性注解，复杂规则需在服务层手动检查。
• 检查业务规则，例如“用户名不能重复”：
- 调用仓储查询数据库，确认用户是否存在
- 验证金额不能为负、订单状态转换是否合法等
public async Task<bool> CreateUserService(User user)
{
var existingUser = await _userRepository.GetByEmailAsync(user.Email);
if (existingUser != null)
{
throw new InvalidOperationException("该邮箱已被注册");
}
// 其他业务规则...
await _userRepository.AddAsync(user);
return true;
}
3. 数据访问层与数据库约束（最终保障）
即使上层验证完备，数据库仍应设置约束，防止非法数据直接绕过应用写入。
• 使用数据库的：- 主键、唯一约束（UNIQUE）防止重复数据
- 非空约束（NOT NULL）保证关键字段存在
- 检查约束（CHECK）限制值范围
- 外键约束维护关联完整性
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<User>()
.HasIndex(u => u.Email)
.IsUnique();
modelBuilder.Entity<User>()
.Property(u => u.Age)
.HasDefaultValue(18)
.IsRequired();
}
4. 验证应在哪些阶段进行？
理想情况下，验证是分层进行的：
- 客户端：提供即时反馈（如JavaScript表单验证）
- API/输入层：使用数据注解拦截明显错误
- 服务层：执行复杂业务规则和跨字段验证
- 数据库层：作为最后一道防线，确保数据一致性
不能只依赖某一层。例如，仅靠数据库唯一约束会抛出异常，体验差；而只做前端验证容易被绕过。
基本上就这些。关键是层层设防，早发现早处理，同时保障安全与数据完整性。
