0

Given a webApi controller like this:

public class MapsController : OwinApiController
{

    private readonly IStorageAccountCache _mapCache;
    public MapsController(IStorageAccountCache mapCache)
    {

        this._mapCache = mapCache;
        this._mapCache = Configuration.DependencyResolver.GetService(typeof(IStorageAccountCache)) as IStorageAccountCache
    }
}

Is ther any different to accessing the dependency resolver by the Configuration instead of getting the value from constructor?

Reason of interest is that given a fairly large controller with alot of dependencies and many action that only uses a subset of these i was considering if using the Configuration.DependencyResolver.GetService in those actions where the dependency is only needed in specific action.

Also, if doing Configuration.DependencyResolver.GetService, has it already called the begin scope according to constructing the controller or should I do a begin scope first.

Poul K. Sørensen
  • 16,950
  • 21
  • 126
  • 283
  • possible duplicate of [Is IDependencyResolver an anti-pattern?](http://stackoverflow.com/questions/5653783/is-idependencyresolver-an-anti-pattern) – Ian Mercer Oct 20 '14 at 22:07
  • I dont see how that is a duplicate, it do not answer my question atleast – Poul K. Sørensen Oct 20 '14 at 22:16
  • I dont even talk about the IDependencyResolver interface. I just want to know if webapi 2 is using Configuration.DependencyResolver to create the objects that are specified as constructor agruments. – Poul K. Sørensen Oct 20 '14 at 22:17
  • The other question, answer and related links explains why constructor injection is preferred. You've already noticed the lifetime management issues caused by resolving dependencies yourself. If all you want to know is how it works internally, just fire up reflector or look at the source code. – Ian Mercer Oct 20 '14 at 22:31

1 Answers1

2

IoC.Resolve<> is an example of the Service Locator pattern. That pattern imposes a few restrictions that constructor injection does not:

  1. Objects can have no more fine-grained context than the application domain, due to the static calls
  2. Objects decide which versions of dependencies to resolve. All instances of a certain class will get the same dependency configuration.
  3. The temptation to couple code to the container is high, for example instead of creating an intention-revealing factory.
  4. Unit testing requires container configuration, where the classes could just be created and used otherwise. (This is especially troublesome when you want to test multiple configurations of the same class, due to the second issue above.)
  5. An application's structure cannot be inferred from its public API. (Constructor parameters are a good thing. They are not a problem you should feel the need to solve.)

These limitations, in my mind, relegate the Service Locator pattern to a middle ground between big-ball-of-mud and dependency injection: useful if you must use it, but by far not the best choice.

Mohammad sadegh Negahbanfard
  • 139
  • 1
  • 5