Circular Dependency Solution

Question

Our current project has ran into a circular dependency issue. Our business logic assembly is using classes and static methods from our SharedLibrary assembly. The SharedLibr

Answer 1

Anytime you have a "shared" library you absolutely must not ever reference your business entity project. Doing so will cause this issue to happen as you obviously see.

The solution to this is remove all of the business entity dependent code from the shared library and either rearchitect away the need for that helper code or place that helper code inside the business entity project itself.

Answer 2

One solution would be to put a facade pattern in between. Here you would avoid direct access/dependency to your business objects from the shared library. Instead, you would be using a layer that acts as a facade between your lib and BOs. This way you can pack your shared libraries clean and decoupled.

Answer 3

You could create a separate project only for value objects (no logic) and interfaces.

Have your shared library classes implement the interfaces, and the Business library depend on the interfaces (do I hear more testable and decoupled code here? Not to mention you remove the dependency from the Shared Library).

Ideally, you could have the business objects on which your shared library depend on this extra project too. If the business objects are too complex, you could also transform them into interfaces.

You will have both projects not depending on each other, but only on another project with only "dummy" objects (no logic):

Business ---> Interfaces and value objects <--- Shared Library

Now those are decoupled =)