数据层验证：Fluent API还是Data Annotations？多ORM支持最佳实践

我来分享下我对这个问题的实际经验和看法，帮你理清两种方案的适用场景：

1. 先明确两种方案的核心差异 #

• Data Annotations：直接标记在模型类的属性上（比如[StringLength(50)]、[RegularExpression(@"^\d{3}-\d{2}-\d{4}$")]），属于声明式验证。只要ORM支持数据注解（大部分主流ORM像EF Core、NHibernate、Dapper.Extensions都支持），验证规则就能跨ORM生效。但缺点是规则和模型强耦合，复杂联动规则的扩展性稍弱。
• EF Core Fluent API：在OnModelCreating方法里集中配置验证逻辑（比如builder.Entity<User>().Property(u => u.PhoneNumber).IsRequired().Matches(@"^\d{11}$")），属于配置式验证。规则和模型分离，但仅限EF Core使用——如果你以后切换到其他ORM，这些规则直接失效。

2. 针对你的需求的优先级建议 #

如果你的核心诉求是验证规则能在所有ORM服务中生效，那么优先选Data Annotations是更稳妥的方案：

• 通用性拉满，只要ORM兼容数据注解，就能自动应用这些基础格式、长度、正则类的验证。
• 遇到复杂的多属性联动验证，还可以让模型实现IValidatableObject接口，写自定义验证方法，同样能跨ORM生效。

当然，如果你已经深度绑定EF Core，且短期内完全没有切换ORM的计划，Fluent API也有它的优势：

• 规则集中管理在DbContext里，模型类更干净，适合团队统一管控数据库映射和验证规则。
• 一些EF Core独有的数据库层面约束（比如HasCheckConstraint配置检查约束、HasIndex做唯一索引），只能通过Fluent API实现。

3. 进阶方案：分层兼顾通用性与灵活性 #

如果想两头都占，可以试试分层验证的思路：

• 数据层实体类用Data Annotations做基础的格式、长度、必填验证，保证跨ORM可用。
• 针对EF Core特有的数据库约束（比如唯一索引、检查约束），用Fluent API补充配置，确保数据库层面也能强制执行规则。
• 业务逻辑相关的复杂验证（比如用户注册时的手机号已存在校验），单独抽离到业务层的验证服务中，别和数据层耦合。

给你举个简单的代码示例：

Data Annotations 基础验证示例 #

public class User
{
    public int Id { get; set; }
    
    [Required(ErrorMessage = "用户名不能为空")]
    [StringLength(50, ErrorMessage = "用户名长度不能超过50位")]
    public string Username { get; set; }
    
    [RegularExpression(@"^\d{11}$", ErrorMessage = "手机号必须是11位数字")]
    public string PhoneNumber { get; set; }
}

EF Core Fluent API 补充数据库约束示例 #

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    // 配置用户名唯一索引，这个只能通过Fluent API实现
    modelBuilder.Entity<User>()
        .HasIndex(u => u.Username)
        .IsUnique();
    
    // 给手机号加数据库层面的长度检查约束
    modelBuilder.Entity<User>()
        .Property(u => u.PhoneNumber)
        .HasCheckConstraint("CK_User_PhoneNumberLength", "LEN(PhoneNumber) = 11");
}

这样既保证了基础验证跨ORM生效，又利用EF Core的特性强化了数据库层面的可靠性。

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