Circular dependency tree, justified or not

问题

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.

This is, more or less, the dependency tree:

• 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) 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) Here's where the dependency cycle happens}

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.

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.

回答1:

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.

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

• 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.

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

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.

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.

来源：https://stackoverflow.com/questions/43472130/circular-dependency-tree-justified-or-not