Dependency Injection in C# and .NET with the Autofac Library

Let's get familiar with the two key terms: DI and IoC.

A discussion of the different DI frameworks that exist. There are many!

How to install and start using Autofac. Very easy, actually, since Autofac is available on NuGet.

Time to get started learning Autofac. Here's what we've got in store for this section.

The key scenario which we're going to be using throughout most of the lessons in this course. No dependency injection yet, that will come in the next lesson!

Time to use Autofac! We register some components and watch the container weave its magic.

What happens if you register multiple components for the ILog service?

If your class has multiple constructors, how does the container know which one to call?

Instead of registering a type to be created on demand, you can define an existing instance to be used whenever a component of a particular type is required.

You can make component registrations using lambda expressions instead of type parameters. This affords additional flexibility.

What happens when you try to register (and subsequently resolve) generic types?

A summary of all the things we've learned in this section of the course.

An overview of the things we're going to encounter in this section of the course.

We look at how parameters can be explicitly passed into the constructor of the instantiated component at the registration stage. We also look at an example of a lambda expression component that delays parameter value passing until the resolution stage.

Parameter passing is a little clumsy, so delegate factories provide an alternative approach.

One common problem when working with DI is how to resolve a type at an arbitrary point in your code. Well, delegate methods are very useful for this.

The constructor is the default way of adding dependencies, but you can also inject them into properties or specify methods that explicitly assign the dependencies.

Registering components one by one is tedious. How about registering all components from an assembly?

We introduce the concept of a module as a self-contained registration unit.

A summary of all the things we've met in this section of the course.

An overview of the things we are going to encounter in this section of the course.

Configuring components that you don't need to be constructed straight away.

What if a component wants to take responsibility for another component's lifetime?

Auto-generated factories and why you might need them.

Now that we're using Func<>, what about passing in parameters?

What happens when you inject an IEnumerable or similar collection interface.

Attaching metadata to components and reading them inside these components.

Accessing a specific service by key. Kind of like Enumeration injection, but with an IDictionary.

A cautionary note about getting too dependent on your DI container.

A summary of the things we've learned in this section of the course.

A taste of things to come.

Scopes are used to control the lifetime of created components.

What happens when long-lived components accidentally (or deliberately) hold onto short-lived components?

A discussion of how objects are cleaned up when created in different scopes.

You can catch events related to lifetime changes on a component.

Learn about startable components.

A summary of all the things we've learned in this section of the course.

A look at the things we'll encounter in this section of the course.

What's the point of modules when we have individual components?

A live demo of how modules are defined and used.

Using Microsoft Configuration Extensions, you can configure the Autofac container externally using an XML or JSON file.

A look at some of the options for configuring your components in XML/JSON files.

A look at how to configure modules in XML or JSON files.

A summary of the things we've learned in this section.

A look at the things we'll encounter in this section of the course.

Customize the container by specifying additional classes that provide their own custom registrations. 

Automatically register adapters; if Foo is an adapter for IBar, ensure that c.Resolve<IList<Foo>>() gets several instances of Foo, one for each available IBar.

If Foo implements IFoo but Bar also implements IFoo and is a decorator of Bar, ensure that requests for an IFoo yield a Bar that is injected an instance of Foo.

Can two components reference each other and be resolved correctly by the container?

Metadata can be provided using Meta<T>, but thanks to Autofac's MEF integration, you can also attach it to classes using attributes, and then use other attributes to perform filtering on this metadata.

What happens when your component depends on too many other components? Can we avoid having a super-long constructor?

Leveraging the power of Castle.DynamicProxy to do some aspect-oriented programming.

A summary of all the things we've learned in this section of the course.

A look at how to start using Autofac with ASP.NET MVC projects.

A summary of the the things we've learned in this course and where to get more info.