如何解决ASP.NET Core多项目分层架构的循环引用问题

架构老林

2026-8-28

分层架构下自定义属性验证循环依赖的可行解决思路

核心矛盾本质是分层职责边界与跨层依赖的冲突，以下是可落地的方案，按推荐优先级排序：

方案1：特性标记与验证逻辑分离，采用注册式校验管道
完全不改动现有依赖链路，把「标记」和「执行」拆到不同层：
1. 在Models项目中仅定义无业务逻辑的空标记特性，比如[ExistsInDatabase]，特性内只保留需要的元数据（比如对应实体类型、字段名），不写任何需要访问数据库/Service的逻辑，仅用于给属性打标记。
2. 在Service层或Api层实现对应特性的校验处理器，比如为[ExistsInDatabase]写专门的ExistsInDatabaseValidator，处理器里可以正常通过依赖注入拿到Service、仓储实例，实现查库校验逻辑。
3. 应用启动时，通过反射把所有「标记特性-校验处理器」的映射关系注册到IoC容器；在Api的模型绑定管道、或者Service层的入参拦截器中，扫描入参对象的所有属性，找到对应标记特性后，从容器解析匹配的校验处理器执行校验即可。
  示例标记特性代码（放在Models层）：
```
[AttributeUsage(AttributeTargets.Property)]
public class ExistsInDatabaseAttribute : Attribute
{
    public Type EntityType { get; init; }
    public string MatchProperty { get; init; } = "Id";
}
```
该方案没有任何循环依赖风险，对现有代码侵入性极低。
方案2：新增独立的校验抽象公共层
微调现有依赖结构，在现有四层之外新增一个最底层的ValidationAbstractions项目，让Api、Services、DataAccess、Models四个项目都引用这个抽象层：
1. 抽象层里放两类内容：一是所有自定义验证特性的定义，二是校验逻辑需要的接口契约（比如IDataExistenceChecker，只定义Task<bool> ExistsAsync<T>(object key)这类方法签名，不写实现）。
2. Models层的属性可以正常引用抽象层里的验证特性做标注，不需要依赖任何上层项目。
3. Service层引用抽象层后，实现IDataExistenceChecker接口，内部直接注入DataAccess的仓储完成数据库查询逻辑。
4. 校验执行时，从IoC容器解析对应接口的实现即可完成校验，不会出现反向依赖。
  该方案适合后续要做大量通用跨层校验的场景，职责拆分清晰。
方案3：拆分校验类型，把业务校验移出Models层
绝大多数场景下这个问题的根源是混淆了两类校验的职责边界：
1. 模型格式校验：比如必填、长度限制、正则匹配、值范围这类不需要任何外部依赖、纯内存就能完成的校验，适合放在Models层的属性标注里。
2. 业务规则校验：比如查库判断数据是否存在、权限校验、外部接口状态校验这类需要依赖服务/IO的逻辑，本质属于业务逻辑，天生就不应该放在Models层的属性特性里。
  你可以直接把需要查库的存在性校验从Models的属性标注里移除，要么直接写在Service层对应业务方法的开头，要么在Api层用FluentValidation这类独立校验库，为对应请求模型编写校验规则，规则类里可以直接注入Service实例完成查库校验。
  该方案完全符合分层架构的设计原则，不需要调整项目依赖，维护成本最低。

不推荐方案：在Models层使用服务定位器获取Service实例
即在验证特性的IsValid方法里，通过静态服务容器、当前HttpContext直接获取全局注册的Service实例执行校验。这种方式虽然能快速实现功能，但会让Models层隐式依赖上层服务，单元测试难度极高，完全破坏分层的依赖约束，除非是极端兼容老系统的场景，否则不要用。

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