循环依赖树，是否合理 [英] Circular dependency tree, justified or not

问题描述

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

I've came up with some solution on which my IoC/DI container (Castle Windsor) is claiming that there's a cyclic dependency tree. And it's true. But I'm not that sure that this cycle is that harmful.

这或多或少是依赖树：

• WebAPI控制器取决于...


• ... a 服务A 取决于...


• ...工作单元取决于...


• ...存储库取决于...


• ...域事件管理器^（1）取决于许多...


• ...域事件处理程序，并且一个依赖于此。 ..


• ... 服务A ^（2）

• A WebAPI controller depends on...
• ...a service A depends on...
• ...an unit of work depends on...
• ...a repository depends on...
• ...a domain event manager⁽¹⁾ depends on many...
• ...domain event handlers, and one depends on...
• ...service A⁽²⁾

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

^{(1) A domain event manager is a generalized class which aims to coordinate concrete domain events to be listened by the same or other domains and perform side actions.}

^{（2）这是依赖性周期发生的地方}

我的域事件管理和处理是在考虑面向方面的编程的情况下实现的，因此，尽管它是依赖关系树的一部分，但是给定的域事件处理程序可能取决于也可能不取决于服务。在同一个依赖树中：我认为域事件处理程序就像其他顶级依赖一样。但是最糟糕的情况已经发生。

My domain event management and handling are implemented with aspect-oriented programming in mind, hence, while it's part of the dependency tree, a given domain event handler may or may not depend on a service in the same dependency tree: I consider the domain event handler like an additional top-level dependency. But the worst case has already happened.

我的观点是，由于 domain事件是跨领域的概念，因此给定的处理程序应该能够注入任何服务，甚至包括已经在给定操作流的依赖关系树中的某些服务。

My point is that, since a domain event is a cross-cutting concept, a given handler should be able to inject any service, even some one that's already in the dependency tree of a given operation flow.

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

For now, I've fixed the issue using property injection in the affected domain event handler, but anyway there could be an alternative to the whole workaround.

推荐答案

从您对设计的抽象定义中很难做到准确，但是在大多数情况下，我经历了循环依赖性，这是违反单一责任原则。

From your abstract definition of your design it is hard to be exact, but I experienced cyclic dependencies for most cases to be the result of Single Responsibility Principle violations.

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

Ask yourself this: can the problem be resolved by breaking service A into multiple smaller independent components, where:

• WebAPI控制器取决于在新的服务Y 上，该服务又取决于现在拆分的服务A 的一个或多个组件。


• 其中一个域事件处理程序

• A WebAPI controller depends on a new service Y that again depends on one or multiple components of the now split service A.
• Where one domain event handler depends on one of the segregated components of the former service A.

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

If the answer to that question is: yes, it is very likely that service A was too big, and took too much responsibility.

这些问题通常与接口隔离原则，因为您最终将获得具有更集中API的较小组件。

These issues are often closely related to the Interface Segregation Principle, because you will end up with smaller components with a more focused API. More than often those components will have just one public method.

本书第6章。NET第二版中的依赖注入，详细介绍了依赖周期以及它们是由违反SRP引起的。

Chapter 6 of the book Dependency Injection in .NET, second edition, goes into much detail about Dependency Cycles and them being caused by SRP violations.

这篇关于循环依赖树，是否合理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！