.NET 6 Clean Architecture：为何WebApi需引用Infrastructure层？

为什么WebApi需要引用Infrastructure层？ #

这本质是依赖注入（DI）的职责要求：

• Application层会定义业务所需的抽象接口（比如IUserRepository、INotificationService），而这些接口的具体实现都放在Infrastructure层（比如用EF Core实现的EfCoreUserRepository、用第三方邮件服务实现的SendGridNotificationService）。
• WebApi作为应用的入口层，负责启动时的DI容器配置——它需要知道这些具体实现类的存在，才能把抽象接口和具体实现绑定起来，所以必须引用Infrastructure层来访问这些实现类型。

这种引用会不会造成不可接受的强耦合？ #

不会，因为Clean Architecture的核心依赖规则是内层不依赖外层：

• 核心的Application层（业务逻辑、用例）完全不依赖Infrastructure层，它只依赖自己定义的抽象。哪怕你替换整个Infrastructure层（比如把EF Core换成Dapper），只要新的实现符合Application层的抽象契约，Application层不需要任何修改。
• WebApi层本身属于「外部适配层」，它的职责就是处理和外部框架、基础设施的对接，这种对Infrastructure层的依赖是它的职责范围内的，属于可控的弱耦合，而非核心逻辑的强耦合。

修改Infrastructure层会导致WebApi崩溃吗？ #

取决于修改是否遵循契约：

• 如果修改是在符合Application层抽象契约的前提下进行的（比如优化EF Core查询逻辑、替换邮件服务但保持INotificationService的方法签名不变），那么WebApi层不需要任何改动，也不会出现崩溃。
• 如果修改破坏了契约（比如修改了抽象接口的方法签名、删除了DI所需的实现类），那确实会导致WebApi的DI注册失败或调用出错，但这是违反依赖倒置原则的错误操作，不是架构设计的问题——正确的做法是先修改Application层的抽象（如果业务需要），再同步修改Infrastructure的实现，最后调整WebApi的DI配置（如果需要）。

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