In this video, I am taking a sample application and show you how to use Dependency Injection using Autofac. I am sharing how to wire up dependencies both explicitly and implicitly.
Transcript Of The Video
Hi I'm Andrea, and welcome to Productive C#.
In this video I want to tell you how you can get started using Autofac. I'm going to do that by taking an application, and introducing the dependency injection framework using Autofac.
So this application is made of a few classes, and some interfaces. The application class takes the option service, and the printer, and the option service take a numeric store and a printer, numeric store will take a printer. So you can see that there is a graph of object that are initialised in the main here, before running the application.
The details of this application are not strictly important for the purpose of this exercise. I'm not going to the details.
As you can see, however, this application is already using the constructor injection pattern in order to wire dependencies. As you can see the application for the sample class is taking all the dependencies it needs from the constructor. This is a very good pattern to follow, and the same is for the option service, for example, is taking the INumericStore and the IPrinter as a dependency in the constructor.
This allows you to keep the system loosely coupled, help maintainability and make the system testable. However, if you have a big graph of objects, creating objects manually might be problematic so that's where dependency injection framework comes into place because it can helps you to do initialization for you, automatically.
Okay, so first the thing to do is to actually add the dependencies to Autofac, using NuGet. I already did that. This is Autofac version 4.8.1.
Okay, so let me remove this code and try to use Autofac. So the first things you need to do is to create a container. And I'm going to create a method. Build container. And, this method here, we return. Add a container. This is an object that Autofac provides. In order to create a container, I need to create a builder. A new container builder. The container builder is where you do the configuration. So, here I'm not doing that now. And I want to build the container.
So the container is an important option in Autofac that allows you to configure how you want to resolve dependencies inside the application. As soon as you then have a container, you can create a scope using the method, begin lifetime scope, and inside here I can resolve dependencies using the resolve method.
I am going to resolve the application type. And then I get an application, and then I can run it. Okay? So, this is really the basic and the most simple things I can do to get Autofac wired in. As you can see, I'm not doing any new at all in the application, so all the initialization of the objects is done automatically by the framework.
So, what happen if they going to run this application? So it's going to fail. As you can see, saying that the application has not been registered. So, by default when you create a container, Autofac doesn't know how to create your objects, so it requires explicit registration in order to be able to know which kind of objects to resolve.
So we are going to need to tell Autofac how to build our objects. So we're going to tell, okay, if you get a type application, then create an application. That's how you can say, like if you need to create an instance of application, use application. If instead you want to use register a type using an interface, you need to do something like that, that say the option service would be accessed using the IOption service. Right? So now all the time the framework needs to resolve an instance of an IOption service, we'll create an instance of OptionService.
I can follow the same pattern for all the others objects I need, like for the printer, that will implement IPrinter, and then for the InMemoryNumbericStorethat implements INumericStore. Now if I run it, let's see if I've got all the information I need. Yes. And it's actually printing the "Enabling the option" and doing something.
Okay. Of course, this application is small enough and you don't really understand why I did all of this work, like it was probably easier to understand before. And I definitely do not recommend to use a ID framework unless you really have a complex dependencies of objects that you need to resolve. But you get the idea.
Okay, so what happen is that when scope resolve is called, the framework automatically feed it application takes two objects in the constructor and basically recursively create an instance of all those objects by using the configuration inside the container. That's basically how it works.
However you can simplify this by creating a sort of implicit registration, so it's quite commonly done at that interfaces are IName, and then the class will basically be the same without the I. So we can actually use an implicit registration so that the framework automatically does it for you without every time you add a class to also add a register type meted in the container. So, I can do something like this, I can do register Assembly types, then you get the current Assembly. Oops, we had current Assembly, Executing Assembly. There we go. Then, you do AsSelf. So this method say, every class, if you actually look for a particular class, not an interface or a absolute class, just resolve with self. Also if you find an interface, just automatically use the default on a convention.
So you just do one thing online and then the programme should still work as before, but now you can actually add a new type and the framework automatically works without you having to monitor register, like for example let me create a new class, I can just copy printer, and I'm going to create another printer, or we'll say an email service, whatever it is. Right, this is going to be an email service. That's not going to be implementing anything for example, it doesn't particular matter what I'm going to do. Let's say I'm going to send an email, something like that. Okay? If I then add the email service to the option service let's say, I'm going to inject an email service here, will this still work if I run it?
Is this still works. So the frameworks knows what it needs, when it creates an OptionService, need to create an EmailService automatically. So you don't need to do anything and it just works.
And this really is the basic of Autofac. Of course, in this case we have two implementation of an interface like we have an InMemoryNumericStore, it implements INumericStore. And we have a FileNumericStore, it implements an INumericStore. So in this case we already know which one has been used, right, between the two so, let's see to put a breakpoint and see which one has actually been created by the framework.
So in those situation you probably want to override the configurations to say exactly which one you want. You don't want to rely on how the framework does it. So you can always obviously register the type you want explicitly.
Okay, so basically now you converted your application, and as the application grows you can add the interfaces and types and you can wire them in in your graph of objects without having to manually instanciate them.
so why do we want to use a framework? Because it helps to wire up complex objects relationships, if you have a big application, and allows you to control even when the objects are created and how many instances are created by using the scopes and the configuration. Of course we are going to look at this information in other videos. And ultimately helps you to write less boilerplate code. And in big applications the part of the code actually does the instantiation of the objects and the configuration can be quite annoying, so I've worked in a big application where there was no DI framework used and there was quite a lot of instanciation going on. So the framework can help to remove some of the boilerplate code.
So, this is really a very quick introduction to Autofac, and I hope you enjoyed this video, and thank you very much for watching.
If you like this video, I invite you to check out My Productive C#. My Productive C# is the essential resource for any developer at any stage of their career to increase their practical skills and become master C# developer. So whether you are still figuring out how to get your first on net developer job, or whether you are already an experienced C# developer, and you are just looking for ways to stay up to date, then My Productive C# can help you to get to the next level. With an extensive collection of extremely practical videos, weekly news, free licences from sponsors, exclusive access to me, and a supportive community to help you along the way with feedback, encouragement and advice, My Productive C# is the perfect place for anyone looking to become a master and successful C# developer. So check it out on Productivecsharp.com/membership.