我在各个网站上看到了几篇文章,它们提出使用依赖注入来解决.NET程序集之间的循环依赖问题。这可能可以解决构建错误,但实际上并没有真正解决循环依赖问题,对吧?对我来说,架构中似乎仍然存在逻辑错误。是我疯了还是其他人也有同感?
- 这不是依赖注入的最佳用法?
- 这不是解决循环依赖问题的适当方式?
我在各个网站上看到了几篇文章,它们提出使用依赖注入来解决.NET程序集之间的循环依赖问题。这可能可以解决构建错误,但实际上并没有真正解决循环依赖问题,对吧?对我来说,架构中似乎仍然存在逻辑错误。是我疯了还是其他人也有同感?
http://misko.hevery.com/2008/08/01/circular-dependency-in-constructors-and-dependency-injection/
相同的答案在以下帖子中返回(我将添加参考资料),即创建一个第三个类依赖的类。这意味着您正在违反单一职责原则。通过将两个类都依赖的责任移动(提取)到一个单独的类中,您将删除循环依赖关系。
FYI 维基百科上的单一职责模式
其他人的StackOverflow讨论:
我的StackOverflow答案,其中包含提取责任的示例。
DI(依赖注入)不是用于解决循环依赖关系,而是为了促进创建良好解耦的组件,从而使它们更易于测试。
我想在这里补充一点我的观点,因为我通过搜索“去除循环依赖”找到了这篇有用的帖子。
是的。您可以使用DI来解决循环依赖问题。解决任何问题的第一步是找到它。Ninject在引导时会抱怨我的循环依赖,并抛出一个有用的异常。Ninject为我找到了它,并迫使我修复它。我可以作弊并使用属性注入或方法注入,但这会破坏我的类不变性保护(我认为这就是您抱怨的原因)。
所以,通过IoC使用构造函数注入,因为它会为您检测循环依赖关系。接下来就由您自己重构和消除架构错误了。