resolving circular dependencies with dependency injection

Question

I've seen several articles on various websites that propose resolving circular dependencies between .NET assemblies by using dependency injection. This may resolve the build errors but it's not really resolving the circular dependency, is it? To me, there seems to still be a logical error in the architecture. Am I crazy or do others agree 1) this is a less than stellar use of DI, and 2) not the appropriate way to solve circular dependency issues?

Answer 1

I agree with you. The first step in solving a circular dependency should be to look for errors in the architecture.

Answer 2

DI is not for circular dependency resolution but rather for facilitating the creation of nicely decoupled components and thus more testable ones.

Answer 3

If you have circular dependencies between two objects, it means you need a third object, on which the two objects will depend on, so they won't depend on each other. Here is an article that is the exact solution to your problem:

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

Answer 4

1. Yes, you make it even harder to detect them by using an extra layer of abstraction.
2. You absolutely do not solve the circular dependency but hide it by adding an extra layer of abstraction, using late bounding, or/and loosely coupling it.

The same answer returns in the following posts (which I will add for references) which is create a 3rd class on which both depend. This translates to: you are violating the Single Responsibility Principle. By moving (extracting) the responsibility both classes depend on in a separate class you'll remove the circular dependency.

FYI the Single Responsibility Pattern on Wikipedia

StackOverflow discussions by others:

• business-logic-layer-and-data-access-layer-circular-dependency
• are-circular-class-dependencies-bad-from-a-coding-style-point-of-view

My answer on StackOverflow with an example of extracting the responsibility in a seperate class.