循环依赖树，是否合理

我想出了一些解决方案，我的IoC / DI容器（ Castle Windsor ）声称有一个循环依赖树。这是真的。但我不确定这个循环是否有害。

这或多或少是依赖树：

^{（1）域事件管理器是一个通用类，旨在协调由相同或其他域监听的具体域事件并执行副操作。}

^{（2）这是依赖循环发生的地方}

我的域事件管理和处理是在考虑面向方面的编程时实现的，因此，虽然它是依赖树的一部分，但给定的域事件处理程序可能依赖于或不依赖于同一依赖树中的服务：我认为域事件处理程序，如额外的顶级依赖项 。但最坏的情况已经发生了。

我的观点是，由于域事件是一个交叉概念，给定的处理程序应该能够注入任何服务，甚至是已经存在于给定操作流的依赖树中的某个服务。

目前，我已经在受影响的域事件处理程序中使用属性注入修复了该问题，但无论如何可能有替代整个解决方法。

从您的设计的抽象定义很难准确，但我经历了大多数情况下的循环依赖，这是单一责任原则违规的结果。

问问自己：通过将服务A分解为多个较小的独立组件可以解决问题，其中：

如果问题的答案是：是的， 服务A很可能太大了，并且承担了太多的责任。

这些问题通常与接口隔离原则密切相关，因为最终会使用更集中的API来构建更小的组件。这些组件通常只有一种公共方法。

“ dependency injection在.NET中的第二版 ”一书的第6章详细介绍了依赖循环，它们是由SRP违规引起的。