.net - 使用依赖注入解决循环依赖

Question

我在各种网站上看到了几篇文章，这些文章建议通过使用依赖注入来解决 .NET 程序集之间的循环依赖关系。这可能会解决构建错误，但它并没有真正解决循环依赖，是吗？对我来说，架构中似乎仍然存在逻辑错误。我疯了还是别人同意？

1. 这是对 DI 的不太出色的使用吗？
2. 不是解决循环依赖问题的合适方法吗？

Answer 1

如果两个对象之间存在循环依赖关系，则意味着您需要第三个对象，这两个对象将依赖该对象，因此它们不会相互依赖。这是一篇文章，它是您问题的确切解决方案：

http://misko.hevery.com/2008/08/01/circular-dependency-in-constructors-and-dependency-injection/

Answer 2

1. 是的，您通过使用额外的抽象层使检测它们变得更加困难。
2. 您绝对不会解决循环依赖，而是通过添加额外的抽象层、使用后期边界或/和松散耦合来隐藏它。

以下帖子（我将添加以供参考）中返回相同的答案，即创建两者都依赖的第三类。这转化为：您违反了单一职责原则。通过在一个单独的类中移动（提取）两个类所依赖的责任，您将删除循环依赖。

仅供参考，维基百科上的单一职责模式

其他人的 StackOverflow 讨论：

• 业务逻辑层和数据访问层循环依赖
• 从编码风格的观点来看，是循环类依赖关系不好

我在 StackOverflow 上的回答是在单独的类中提取责任的示例。

Answer 3

DI 不是用于循环依赖解析，而是用于促进创建良好解耦的组件，从而促进更可测试的组件。

Answer 4

我将在这里投入 0.02 美元，因为我通过搜索“消除周期性依赖项”发现了这篇有用的帖子

是的。您可以使用 DI 来解决循环依赖关系。解决任何问题的第一步是找到它。Ninject 抱怨我的循环依赖并在引导时抛出了一个有用的异常。Ninject 为我找到了它并强迫我修复它。我可以作弊并使用属性注入或方法注入，但这破坏了我对类不变量的保护（我认为这是您所抱怨的）。

因此，通过 IoC 投票支持 ctor 注入，因为它会为您发现循环依赖关系。然后由您来重构和删除架构错误。