There is an unsaved comment in progress. You will lose your changes if you continue. Are you sure you want to reopen the work item?
Separate service location from dependency injection
There is a lot of confusion today about how Web API uses service location vs. dependency injection, caused in no small part by the fact that both activities today are performed against IDependencyResolver.
Service location is about creating objects which are only created once for the lifetime of the configuration and then generally cached for further use. Dependency injection is used to create objects which have a transient lifetime (typically a per-request lifetime,
though this is not necessarily dictated in the contract of the dependency resolver).
Service location will live in a new property, HttpConfiguration.Services, which is not user pluggable. This service list will be populated with the known default services present in the application, and the application developer can add and remove services
from this list. These services are considered to be "global" to the configuration, and the single instance of these services is shared across all requests. Only known service types will be gettable or settable in the service locator.
Dependency injection will continue to use IDependencyResolver, which will be user pluggable. Web API itself will only use dependency injection (directly) for one type of object creation in this version: for controller creation. IDependencyResolver will get
a new Release method, which will be used to return any objects that were obtained from IDependencyResolver, once the framework is done using them. In addition, by making IDependencyResolver the known "one place" for dependency injection, this will
allow us to add future DI-able types to the framework without rework, as well as allowing application/component developers to rely upon a single place to get transient objects.
By default, the first time a service is requested from the service locator, it will consult the dependency resolver, which means that a user-registered DI container has an opportunity to provide instances of those core Web API services. For calls to GetService(),
the DI container service will take precedence over the default in the service locator; for calls to GetServices(), the DI container results will be prepended to the the results from the service resolver. The services that the service locator gets from DI will
be held onto for the lifetime of the configuration, and then released when the configuration is disposed.