0

Not sure if the title makes sense, but it's the best I could come up with so let me explain. I'm refactoring, mostly rewriting and simplifying, a project in my solution which contains a bunch of "Services" that basically contain my business logic. There's a bunch of services and each one backs a specific object from my Entity Framework implementation. The problem I'm facing is that each service may have dependencies on other services which may have dependencies on yet other services and possibly the calling service. In fact I've actually ran into a circular dependency in the older version of the code which I resolved by cheating it and declaring the generic version of the class. It worked but I wasn't very fond of it.

With the rewrite I'd like to resolve the possibility of circular dependencies happening, but the issue I'm running into is that all services require a repository to be injected into them. Currently Ninject takes care of that for me and probably injects the same repository into all of them when it's building up the objects, but I'm not sure how to maintain the dependencies Ninject takes care of for all services and somehow avoid the possibility of circular references.

I'm looking for suggestions on how to resolve this conundrum.

Gup3rSuR4c
  • 9,145
  • 10
  • 68
  • 126

1 Answers1

0

Declare interfaces for each service and program against these interfaces. If you use constructor injection for the services, these interfaces won't have circular dependencies, because the constructors are not part of the interfaces. These interfaces can be declared together in a separate contracts-only project.

The classes implementing these services will only depend on the interfaces, but not on concrete service-implementations. This way you will not have circular references between projects.

Olivier Jacot-Descombes
  • 104,806
  • 13
  • 138
  • 188