Autofac in .NET MVC Overview and operation diagram - How Autofac’s internal operation helps .NET MVC Controller to achieve Dependency Injection

Autofac can help to achieve the purpose of IOC and DI. How to achieve it internally can refer to this article ”Autofac Process overview diagram-How the package achieves the purpose of IOC” 。The kit can also help to achieve the DI of the MVC architecture, which is actually very convenient to use. But after some understanding of the initial operation of Autofac, some developers who want to know the working principle tend to be curious about how to achieve the principle of DI of .NET MVC, how to do Resolve for MVC Controller constructor sub-parameters?

So outlining how to achieve the purpose of DI, it will be divided into the following order

1. How to use Autofac with .NET MVC architecture
2. Diagram of the process of generating Controller from MVC architecture
3. A brief description of how Autofac implements DI in MVC
4. Take a simple example as an example

The following descriptions will be given:

1. How to use Autofac in .NET MVC framework

First install the Autofac.Integration.Mvc package prior to the .NET MVC project. After the installation is completed, it is also necessary to set the Application_Start in Global.asax.cs first, and register the service for the category of the MVC Controller. The program is:

var builder = new Autofac. ContainerBuilder();

builder.RegisterControllers(typeof(MvcApplication).Assembly);

Then after the control item category is registered, the registration service can be done for the objects to be used by these categories. For example, in HomeController, add a constructor with parameters (and a field member for ILog):

ILog log;

public HomeController(ILog pLog){

log = pLog;

…

}

Without the assistance of DI, we need to do it somewhere in each category

ILog log = new ClsLog();

However, if dozens of Controllers need to use this ClsLog object, if the name of the object needs to be changed one day, it will inevitably be changed dozens of times, and the development efficiency will be reduced.

So we need the help of Autofac DI. Then proceed to the registration service of ClsLog:

builder.RegisterType<ClsLog>().As<ILogC>();

Finally, build the container and complete the final registration of the service:

var container = builder.Build();

DependencyResolver.SetResolver(new AutofacDependencyResolver(container));

DependencyResolver is an object of System.Web.Mvc, and AutofacDependencyResolver is an object of Autofac.Integration.Mvc. After the Autofac container is constructed here, as long as the HomeController is called, the ClsLog entity will be injected into the constructor parameter.

2. Diagram of the process of generating Controller from MVC architecture

So how does Autofac do Resolve to the MVC Controller constructor parameters?

The first thing to study is how MVC generates Controller. The following figure is a simplified diagram of the process of generating Controller entity in MVC 5:

Asp.net MVC 5 process diagram —Execute Action Method

In the above figure, the red box is the key time point when the Controller entity is generated. MvcHandler will get the Factory that generates the Controller. The previous initialization of the Factory will construct the DependencyResolver, and the Controller category will be generated according to the Type, and the System.Reflection component will be used further.

3. A brief description of how Autofac implements DI in MVC

If AutoFac wants to cut in, it is necessary to let Autofac do Resolve at the critical time point mentioned in the previous point, and use the constructor parameters to do recursive Resolve (refer to “How Autofac Suite Achieves IOC Purpose — Overview Diagram”) .

The Autofac.Integration.Mvc component also rewrites the class that applies IDependencyResolver, and changes GetService to be executed by the extension function of the Autofac component:

public virtual object GetService(Type serviceType)

{

return ResolutionExtensions.ResolveOptional(this.RequestLifetimeScope,

serviceType);

}

Therefore, after the Type of the Controller is sent in, it will run TryResolveService and ResolveComponent of the Autofac component, and then recursively pass the parameters of the constructor to Resolve.

And when will this IDependencyResolver content of Autofac.Integration.Mvc be replaced? It is the first point of establishing the container and completing the final registration of the service:

var container = builder.Build();

DependencyResolver.SetResolver(new AutofacDependencyResolver(container));

IDependencyResolver will be replaced here.

4. Use simple examples as examples

Seeing how much you should know about the key time points here, Autofac will take over the Resolve Controller category, at least know that there is such a thing.

Use a simple example to implement MVC Controller Constructor Parameter DI

autofac in asp.net mvc simple example — 1

Set in Application_Start of Global.asax.cs:

autofac in asp.net mvc simple example — 2

Finally, the Controller constructor will receive the registered Service:

autofac in asp.net mvc simple example — 3

The physical memory of the above parameters is of the type ClsLog.

The above is how Autofac uses the Autofac.Integration.Mvc component to implement DI for .NET MVC’s Controller constructor sub-parameters. I hope it can help, and for those who want to know how the truth works, the basic entry point.