使用依赖注入(DI)时如何避免循环依赖？新手技术咨询

嘿，这个问题其实挺典型的，很多刚接触依赖注入的朋友都会碰到类似的引用困境，我来给你拆解下～

首先得明确：你的核心问题不是DI本身导致循环依赖，而是容器配置的位置放错了——把Unity容器的配置放在领域层（Project A）是不合理的，这才引发了A必须引用B的尴尬局面。

1. 调整容器配置位置，直接打破循环引用 #

领域层（Project A）的职责应该是纯粹的：只定义业务接口（比如IRepository）和核心领域逻辑，完全不应该负责DI容器的注册工作。正确的做法是把容器配置放在一个独立的启动项目/配置项目里——比如叫Project Bootstrapper，或者直接放在你的Web项目、控制台项目这类入口项目中：

• 这个启动项目需要同时引用Project A（获取接口定义）和Project B（获取实现类）
• 在这里完成Unity容器的注册操作，比如：

  var container = new UnityContainer();
  container.RegisterType<IRepository, RepositoryImpl>();
  

• 这样一来，Project A和Project B之间就只有B引用A的单向依赖，完全不存在循环。

2. 为什么这种方式能解决问题？ #

DI的核心思想之一就是分离关注点：

• 领域层只关心「需要什么能力」（定义IRepository）
• 实现层只关心「怎么实现这个能力」（RepositoryImpl实现接口）
• 容器配置层只关心「把哪个实现绑定到哪个接口」
  每个项目各司其职，自然就避免了循环引用的可能。

3. 额外的灵活优化方案 #

如果想让项目结构更松散、更易于维护，还可以试试这些技巧：

• 程序集扫描自动注册：Unity支持从指定目录加载程序集，自动找到IRepository的实现类完成注册。这样启动项目甚至不用直接引用Project B，进一步降低耦合度
• 模块化注册：在Project B中封装一个RepositoryModule类，把注册逻辑写在里面，启动项目只需要加载这个模块即可，不用手动写注册代码，后续新增实现也更方便

举个程序集扫描的代码示例：

var container = new UnityContainer();
// 从当前程序集所在目录加载所有程序集，自动匹配接口和实现
container.RegisterTypes(
    AllClasses.FromAssembliesInBasePath(),
    WithMappings.FromMatchingInterface,
    WithName.Default
);

总结一下：循环依赖不是DI的问题，是你把容器配置的位置放错了。把配置逻辑从领域层移到独立的启动入口层，让各层职责清晰，循环问题自然就迎刃而解啦～

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