Your official information source from the .NET Web Development and Tools group at Microsoft.
Dependency Injection (DI) is a software design pattern, a particular case of the Inversion of Control pattern, in which one or more dependencies are injected into dependent objects. The pattern is used to create program designs that are loosely coupled and testable.
This article assumes that you are already familiar with DI. If not, you can read this article for a brief introduction.
In ASP.NET vNext, dependency injection is a first class citizen. While in the previous versions of the framework, DI was partially supported, in ASP.NET vNext it is available throughout the entire stack. A minimalistic DI container is provided out of the box but we are leaving the door open to BYOC (Bring Your Own Container). The default container is useful in the cases when you don’t need any advanced injection capabilities (see the known limitations section at the end of the post).
BYOC is possible because of an abstraction over the actual DI container implementation. The abstraction is the IServiceProvider interface and it represents the least set of container behavior our components are limited to assuming are present. All the framework components (MVC, Routing, SignalR, Entity Framework, etc.) rely only on the capabilities of IServiceProvider, but your own application code can use any feature that your chosen DI container has. When you BYOC, you can replace the default implementation of IServiceProvider with a wrapper around your own container. Once that happens, all the dependency resolution calls will be routed to your own container. In the case when you want to use your own container strictly for your own custom types, we support fallback to our default container.
Because all framework components use the same container to register services, we can now flow dependencies across the stack. This opens the door to new scenarios that were not possible before, like injecting a SignalR broadcaster into an MVC controller action. As we walk up the stack, there are different layers of dependency resolvers. All dependencies are added to a single container and everyone can see everybody else’s services. The single container also addresses the cross-cutting concern customization story. It is trivial in the new stack to change cross-cutting concerns (e.g. logging) via a single entry point.
The out of the box container supports the following lifestyles:
A popular feature for DI in web applications is to create objects that have a single instance per web request. This means that the objects acts as a singleton inside that request but two distinct requests will have different instances of the objects.
In ASP.NET vNext, the Per Request Scope is achieved using a middleware and a scoped lifestyle. The middleware, when invoked, will create a new scoped container which will replace the container for the current request. All the subsequent middleware in the pipeline will then utilize the scoped container. After the request flows through the pipeline and the container middleware is signaled to complete, the scope is destroyed and all the objects created inside it are disposed.
The source code for the ContainerMiddleware, is available on GitHub.
In the rare case in which you need to create your own container scope, you can use the IServiceScopeFactory to do this. When the default implementation of the IServiceProvider is created, the IServiceScopeFactory is one of the services that are registered by default.
For the purpose of showing the differences between DI in the old and new stack, we are going to use an MVC controller that writes a string provided through an injected dependency:
None of the code above is changed between the old and the new stack. The only difference is where and how the dependency are registered and resolved.
In the old MVC stack, controller dependencies are resolved through a custom controller factory. For the purpose of this demo, we are going to implement the Poor Man’s DI and manually compose the dependencies:
The controller factory will inject a concrete implementation (HelloMessageGenerator) of the interface (IMessageGenerator) in the Message controller.
The same code, ported to ASP.NET vNext, doesn’t need a Poor Man’s DI implementation. As mentioned before, in this new stack, a DI container is available out of the box. Thus, all we need to do is tell it what is the mapping between the interface and the concrete implementation.
The default implementation of the controller factory in ASP.NET vNext uses the IServiceProvider to resolve the dependencies. If you BYOC, none of the code above will change. You would only have to tell the application to use a different implementation of IServiceProvider.
The code below shows how the previous sample can be rewritten to use Autofac instead of the out of the box container.
The code uses compiler directives to use Autofac code only for the full .NET 4.5 Framework because Autofac is not available for the .NET Core Framework 4.5. In Visual Studio “14” CTP you can change the target framework of a project by right clicking on it and going to Properties -> Active Target Framework.
In order to compile the code above, you must add the dependency injection dependencies to project.json. Since Autofac is not available for .NET Core Framework 4.5, the Autofac dependency is only defined for in the net45 section:
When using DI, we recommend the following practices:
The out of the box container for ASP.NET vNext Alpha has a few known limitations:
ASP.NET vNext is DI-friendly and it uses dependency injection throughout the stack. While there is a default minimalistic DI container out of the box, you can Bring Your Own Container and use advanced DI capabilities. The source code for Dependency Injection is available on GitHub.
We’d love to hear your feedback. Please provide it in Github, comments on this blog, or the ASP.NET vNext forum. If you ask a question in Stack Overflow, use asp.net-vnexttag.
ASP.NET vNext is an open source project released under Apache License Version 2.0 by Microsoft Open Technologies, Inc. You can follow its progress and find instructions on how to contribute on https://github.com/aspnet.
Really hope Microsoft drops this. I don't look forward to how much of a headache this pattern will be, and it solves virtually nothing. The other comments here are right, this is an anti-pattern and should be avoided at all costs. This is practically a turning point for the whole ASP.NET paradigm.
"... I often find as MVC apps age more and more actions are added to a controller and more dependencies are injected into the controller with each action only using half or a third of the injected dependencies but still paying the overhead tax to create and inject all of the dependencies. I don't know the best solution to this but it would be nice to have properties that are lazy loaded via the container."
What you're looking for is "action injection". This link (below) is a nice article on how to do this. I use it all the time. :)
Looks promising! :)
Using Unity doesn't make any sense for vNext. The whole focus of vNext is to break appart the .NET platform in to components, not shoe horn more stuff in it.
If you want unity, bring it in as a separate package.
Interesting, the comments. Understandably, some people suppose the team has gone too far and others not far enough.
I think it's worth considering that those who do not want to take advantage of DI still can with vNext. E.g. instead of asking for a contract/interface in your default constructor just new up the concrete type like you always would. Am I missing something?
To those who suppose the team has not gone far enough, I expect (hope) that getting your favorite DI container installed and working will be as simple as `Install-Package MyFavDI.VNext` or whatever it is in vNext. Which is to say that the manual steps described in the article will not be needed in the future. Hopefully that's not a pipe dream. Victor, vNext team, please correct me if my assumption is wrong.
Admittedly, I am conflicted about the default DI being able to handle only one constructor. It seems like a fair and fast compromise would be allowing manual specification of the one constructor that will be used when constructing a type that has more than one constructor. That keeps DI explicit by configuration and fast.
Will it be possible to inject dependencies into custom IHttpHandler handlers?