We have a few other scenarios that lead to this design:
The ability to chain containers - As you walk up the execution stack there are different layers of dependency resolvers. The runtime has services, the web hosting has services, the webserver has services, and these should flow freely throughout the system.
One example of this is the fact that MVC uses a service from the core host (KRuntime) to reason about the appliction's dependency graph to find controllers. Everyone can see everybody else's services (which leads me to my next point).
Services can flow across frameworks - This is one thing I've wanted since we did SignalR. Today there's no way to get SignalR's broadcaster into a MVC or WebAPI action. This system makes that just work by default. AddSignalR, AddMvc and boom, services are
freely flowing between the two systems. Now your application can publish from middleware, a controller action and arbitrary class activated with TypeActivator and the power of DI starts to show itself.
DI required by frameworks - Our frameworks all require dependency injection now, it's not an after thought nor do we have our own set of services. This has the same benefits as the previous bullet. Services can flow out of the framework they are defined
in and can be composed.
Cross cutting concerns can be customized across the board - You can replace logging for the entire application via a single entry point.
That's a brain dump (probably not complete) of some of the things that lead to the current approach.
DI
David Fowler
Principal SDE, ASP.NET Team, Microsoft
Contributor
2292 Points
908 Posts
Microsoft
Re: Feedback on ASP.NET vNext Dependency Injection
May 31, 2014 05:43 AM|davidfowl|LINK
We have a few other scenarios that lead to this design:
That's a brain dump (probably not complete) of some of the things that lead to the current approach.
DI
Principal SDE, ASP.NET Team, Microsoft