1

This is a very simple question. I am using a IoC Container to register key depedencies at root level. For the rest of the dependencies, I use constructor injection..

What are the best practices to resolve dependecies between services of the same level of the application?

I could use the IoC Container as service locator, but I agree with some interpretations of Service Locator as Anti-pattern (http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/) and I agree that IoC Container should be focused on modularity and composition roots.

Another alternative is to create an explicit version of the locator where I could explicitly define the dependencies, but now i would be violating the Open-Close principle, because I would need to change "IServices" (and all the implementations of this interface) for each new "ServiceX" interface that I create in the future.

public interface IServices
    {
        IServiceA ServiceA { get; }
        IServiceB ServiceB { get; }
        IServiceC ServiceC { get; }
    }

Now I went out of ideas. Is there an alternative?! Between these two approaches, I think would stay with the explicit version of the dependencies, but I am looking forward to know if there is a design pattern that could fit better to this scenario.

EDIT

Sorry for not being clear. The second approach is a constructor injection too, just like the first. The difference is that instead of passing the IoC Container to the constructor of the implementation of IServiceA, I would pass "IServices", that is a interface that explictly defines the dependencies of "IServicesA".

Minduca
  • 1,121
  • 9
  • 19

1 Answers1

2

I think that using Inheritance to inject dependencies is a non-flexible way to solve your problem. Moreover, it is not convenient way as well: you need to provide implementation of IServices for each service that needs those dependencies, and change them every time you change the contract. Plus, it's hard to test classes with dependencies injected via inheritance - there is no easy way to inject mock objects instead of real dependencies(unless using setters, which is not the best practice in itself).

And you right, using Service Locator is not the best approach as well, if you have another choice.

I think that we best way to go is to provide dependencies via constructor. Thus you control which dependencies to provide(and it doesn't matter whether you use some IoC container or not, you could provide dependencies manually or use the power of IoC container) and you will get testable decoupled design.

I understand that you were talking about dependencies of the same level. So, the only thing to beware of here is circular dependency between your components. I think that you could follow dependencies-via-constructor principle almost every time and do not have any problems, may be you just need to refactor/split your components properly.

Sorry if I misunderstood your question in some way.

alekseevi15
  • 1,732
  • 2
  • 16
  • 20
  • Thank you for your answer. I wasn't considering the idea of inheritance. The second alternative is dependency injection through the constructor. IServicesA would receive IServices through the constructor. Sorry for not being clearer. But indeed, I agree with you and I am aware of the considerations. I just – Minduca Nov 11 '14 at 09:34
  • I just considered that maybe we had some other better alternative. Thank you ;) – Minduca Nov 11 '14 at 09:35
  • 1
    I completely agree. You should ALWAYS go with constructor injection unless proven to be impossible. – Steven Nov 11 '14 at 09:36