Clean Architecture架构下：需通过EF存储的视图相关数据应放置于何处？

嘿，这个问题确实是Clean Architecture实践里很常见的纠结点——既要遵守"领域实体只承载核心业务规则"的原则，又要处理Web视图专属的持久化需求。结合你的场景，我有几个贴合架构原则的方案，按推荐度排序：

1. 新建视图专属的持久化实体（最推荐） #

既然坐标是Web应用独有的视图状态数据，完全没必要污染核心领域的Spot实体。咱们可以在Infrastructure层新建一个专门存储视图坐标的实体，和Spot建立一对一关联：

// Infrastructure层 - 仅服务Web应用的视图配置实体
public class SpotVisualPosition
{
    public Guid SpotId { get; set; } // 用Spot的ID作为主键，实现一对一绑定
    public int ScreenX { get; set; }
    public int ScreenY { get; set; }

    // 导航属性，仅在Infrastructure层使用
    public Spot Spot { get; set; }
}

然后在EF配置里单独处理这个实体，并且让领域的Spot完全不需要知道它的存在：

public class SpotVisualPositionConfiguration : IEntityTypeConfiguration<SpotVisualPosition>
{
    public void Configure(EntityTypeBuilder<SpotVisualPosition> builder)
    {
        if (builder == null) throw new ArgumentNullException(nameof(builder));
        
        // 设置主键为SpotId，确保一个Spot对应一个坐标配置
        builder.HasKey(x => x.SpotId);
        
        // 建立与Spot的一对一关联，领域实体无需反向导航
        builder.HasOne(x => x.Spot)
            .WithOne()
            .HasForeignKey<SpotVisualPosition>(x => x.SpotId)
            .OnDelete(DeleteBehavior.Cascade); // 随Spot删除自动清理坐标
    }
}

这个方案的优势： #

• 完美遵守Clean Architecture的关注点分离：领域实体Spot保持纯净，只承载核心业务规则；视图专属数据完全隔离在基础设施层，仅服务Web应用
• 其他使用Spot的领域完全不受影响，看不到任何视图相关的字段
• 结构清晰，后续维护（比如加更多视图配置项）非常方便

2. 使用EF阴影属性（轻量但隐蔽） #

如果不想新增实体，可以利用EF的阴影属性——不用修改领域Spot的代码，直接在Infrastructure层的配置里添加字段：

public class SpotConfiguration : IEntityTypeConfiguration<Spot>
{
    public void Configure(EntityTypeBuilder<Spot> builder)
    {
        if (builder == null) throw new ArgumentNullException(nameof(builder));
        
        // 原有配置...
        builder.HasOne(x => x.Area)
            .WithMany(x => x.Spots)
            .HasForeignKey(x => x.AreaId);
        builder.Property(x => x.Description)
            .IsRequired()
            .HasMaxLength(10);
            
        // 添加阴影属性存储坐标，领域实体无感知
        builder.Property<int>("ScreenX");
        builder.Property<int>("ScreenY");
    }
}

之后在Web应用的ViewModel映射时，通过EF的Entry API读取这些属性：

var spot = _dbContext.Spots.Find(spotId);
var x = _dbContext.Entry(spot).Property<int>("ScreenX").CurrentValue;
var y = _dbContext.Entry(spot).Property<int>("ScreenY").CurrentValue;

注意点： #

• 优点是不用新增实体，代码改动小
• 缺点是字段比较隐蔽，其他维护者可能不知道这些阴影属性的存在；而且如果其他领域也使用EF操作Spot，数据库里会有这些字段，但不会影响业务逻辑（因为领域实体没有对应的属性）

3. 通用实体配置表（适合多实体视图配置场景） #

如果未来还有其他实体需要存储视图配置，可以建一个通用的EntityVisualConfiguration表，用键值对存储：

public class EntityVisualConfiguration
{
    public Guid Id { get; set; }
    public string EntityType { get; set; } // 比如"Spot"
    public Guid EntityId { get; set; }
    public string ConfigKey { get; set; } // 比如"ScreenX"
    public string ConfigValue { get; set; } // 存储坐标值，需要序列化/反序列化
}

这个方案灵活性很高，但查询和序列化会稍微麻烦一点，适合视图配置需求复杂、涉及多个实体的场景。

综合来看，方案1是最符合Clean Architecture原则的选择，它既保持了领域层的纯净，又清晰地隔离了Web应用专属的持久化细节。

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