EF最佳实践之Shadow Properties：Fluent API与数据注解使用疑问

我通常会创建领域模型，并在其中使用Data Annotations/显式外键关系来定义数据库生成规则，在我看来这种方式可以将最大长度、必填等约束明确集中在一处。
近期我做代码评审时收到反馈，不建议采用上述两种方式，推荐我通过Fluent API/shadow properties为每个模型单独编写配置，这样所有数据库生成逻辑集中存放，同时可以保持领域模型纯净，仅负责处理领域本身逻辑。

调整后代码示例 #

领域模型代码 #

public class Blog
{   
    private HashSet<Comment> comments;
    public IReadOnlyCollection<Comment> Comments => comments;    
    public string Title {get; private set;}
    public string Content {get; private set;}
    public Core.Constants.Blog.Categories Category {get; private set;}

    public Blog(string title, string content, Core.Constants.Blog.Categories category)
    {
        Id = Guid.NewGuid().ToString("D");
        comments = new HashSet<Comment>();
        Title = title;
        Content = content;
        Category = category;
    }
}

public class Comment{
    private string Id {get; private set;}
    public string Identifier { get; private set; }
    public string Description { get; private set; }    
    
    public Comment(string identifier, string description)
    {
        Id = Guid.NewGuid().ToString("D");
        Identifier = identifier;
        Description = description;
    }
}

Fluent 配置代码 #

internal class BlogConfiguration : IEntityTypeConfiguration<Domain.Blog>
{
    public void Configure(EntityTypeBuilder<Domain.Blog> builder)
    {
        builder.ToTable("Blog");

        builder.HasKey("Id").HasName("PK_Blog");

        builder.Property(res => res.Title)
              .IsRequired();

        builder.Property(res => res.Content)
              .IsRequired();
      
        builder.Metadata
            .FindNavigation(nameof(Domain.Blog.Comments))          
            .SetPropertyAccessMode(PropertyAccessMode.Field);
          
        builder.Property(blog => blog.Category)
               .HasConversion(value =>
                                    value.ToString(),
                                    convertedValue => Enum.Parse<Core.Constants.Blog.Categories>(convertedValue));

    }
}
  
internal class CommentConfig : IEntityTypeConfiguration<Domain.Comment>
{
    public void Configure(EntityTypeBuilder<Domain.Comment> builder) {
        builder.ToTable("Comment");

        builder.HasKey("Id").HasName("PK_Comment");

        builder.Property(asset => asset.Identifier)
              .HasMaxLength(25) 
              .IsRequired();

        builder.Property(asset => asset.Description)
           .HasMaxLength(250);

        builder.HasIndex(asset => asset.Identifier).IsUnique();
    }
}

疑问解答 #

问题1：实际项目中我需要为Comment添加指向Blog的反向导航属性，如果我在Comment中显式定义该导航属性，再在Fluent配置中忽略它，这种做法是否不合理？ #

这种做法确实不合理，完全没有必要：

• 如果你的领域逻辑本身需要用到Comment反向查询关联的Blog，那你在Comment里加导航属性后就不应该在Fluent配置里忽略它，否则EF不会维护这个关联的外键关系，代码访问该属性会一直返回null，反而引发业务逻辑异常
• 如果只有EF配置需要这个关联、领域逻辑不需要用到Comment反向查Blog，那你根本不需要在Comment类里加这个属性，直接用*影子属性（Shadow Property）*定义外键即可，在配置类中加一句builder.HasOne<Blog>().WithMany(b => b.Comments).HasForeignKey("BlogId")就能完成关联配置，外键BlogId只会存在于数据库层，不会污染领域模型
• 额外添加无用属性再做忽略，除了增加冗余代码、提高维护成本之外没有任何收益，完全违背了“保持领域模型纯净”的初衷

问题2：在领域模型上使用Data Annotations真的是非常差的实践吗？ #

不是绝对的差，要根据项目架构和定位判断：

• 如果你走的是*纯净领域驱动设计（DDD）*路线，要求领域层完全不依赖任何基础设施层的技术实现（包括EF Core相关包），那Data Annotations属于基础设施的数据库配置逻辑，耦合到领域模型里确实是不好的实践，会导致领域层被EF绑定、无法轻易替换ORM，也会让领域类里混杂大量和业务逻辑无关的配置代码
• 如果你的项目是简单的CRUD应用，没有明确的领域层和基础设施层拆分，也没有更换ORM的需求，那用Data Annotations反而更简洁，把字段约束直接和模型属性放在一起，可读性更高，也不用单独维护一堆Fluent配置类，开发效率更高
• 另外有一类Data Annotations是和业务规则绑定的，比如[Required]如果是业务上这个字段本身就必填，就算不用EF这个规则也成立，这种场景下用Data Annotations也不算坏实践，相当于把业务约束明确定义在模型上；但如果是数据库专属的配置，比如[Column("db_col_name")]、[Index]这类，就不应该放在领域模型里

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