[MUSIC]

Hi, my name is James.

In this workshop, you'll learn about dependency injection and

how to use it in an ASP.NET MVC application.

We'll start with an overview of what dependencies are, and

how dependency injection, or DI,

can help you to improve the manageability and testability of your code.

We'll also see how to select, install, and

configure one of the popular DI containers available for ASP.NET MVC.

And we'll finish up with a look at DI in the ASP.NET Core web framework.

We won't be covering in this workshop how to use

DI with the ASP.NET Web API framework.

That'll be covered in a future course on Web API, see the teacher's notes for

more information.

Here's the project that we'll be using in this workshop,

open in the community edition of Visual Studio 2017.

Our project name is Treehouse.SolarSystem.

If you'd like to follow along, see the teacher's notes for

a link to download the project files.

Our application is a very basic ASP.NET MVC application.

We have a single controller named PlanetsController,

and we have a single model named Planet.

We also have some entity framework related classes in the Data folder.

We have a Context class, a Database Initializer class,

that seeds our database with some data, and a single Repository class.

Let's see what our application does.

And as you might expect, it displays a list of the planets in our solar system,

all nine, I mean eight of them, sorry Pluto.

Let's review how our application displays the list of planets that you just saw.

Here's the index action method that displays the list of planets.

We can see here that it's calling a method called GetPlanets

on a repository private field.

The repository private field is of type Repository, which

you can see in our class constructor, we're instantiating an instance.

We're also instantiating an instance of the Context class, and

passing that into the repository's constructor.

The Repository class, GetPlanets method, is using the Context class to query

the underlying database for the list of planets.

Back in the controller, we can see that we're also overriding the Dispose method,

which is being used to dispose the _context

when our controller is being disposed.

We're doing this in order to control the lifetime of our _context object.

So, what are dependencies?

As we just saw, our controller class, well specifically the index action method,

is dependent upon an instance of the repository class.

And, the repository class is dependent upon an instance of the context class.

This chain of dependencies is sometimes called a dependency tree or

a dependency graph.

The context and repository classes are examples of database or data dependencies.

There are many other types of dependencies that your application might have.

External dependencies, like storage, messaging services,

like email or texting, or any other restful service, or HTTP API.

Or maybe internal dependencies like app settings, user authentication,

session management or really any business logic that's specific to your application,

for instance, maybe a shopping card for an e-commerce application.

Our controller shouldn't really be concerned with instantiating instances

of its dependencies, or controlling the lifetime of those dependencies.

Ideally, we should just be able to ask for our dependencies.

One way to do that would be to declare our dependencies

through constructor parameters.

Let's take a look at what that would look like.

Let's add a parameter of type Repository named repository.

Then, we can replace this instantiation of the repository class with a reference to

that parameter.

We can also get rid of this instantiation of the context class.

And, this boolean disposed private field and the context private field.

Even more, we can get rid of this dispose override.

That's a lot less code, isn't it?

With this approach, the underlying app framework would provide our controller

with an instance of the repository class.

And for our repository class, it would supply an instance of the context class.

And, it would also manage the live time of the context for us.

This technique is known as constructor injection.

Constructor injection is part of a broader design pattern

known as dependency injection.

Dependency injection, or

DI, is related to the inversion of control, or IOC design principle.

As we just saw in our example, using DI classes, like our controller,

no longer need to concern themselves with how their dependencies are instantiated.

In fact, any of our controller's dependencies, like the repository class,

in turn might have their own dependencies.

That's no problem.

It's still not the concern of our controller.

Directly instantiating dependencies within a class,

tightly couples that class to its dependencies.

Using DI helps us to create loosely coupled classes or components.

Loose coupling improves code reusability,

making it easier to reuse our classes in new ways or in new environments.

DI also helps to improve the testability of our code.

For example, if we wanted to unit test our controller's index action method,

we could provide the controller with an instance of the repository class

that would avoid querying the underlying database.

Instead, it'd simply return a static collection of planets.

Supplying this mock repository class to the controller class

would allow our unit test to run in a performant predictable way.

Constructor injection isn't the only way to implement DI.

Property injection and

method injection are two alternative approaches that you can use.

We won't be covering these approaches in this workshop,

as we'll be using constructor injection.

For more information about the IOC design principle, property injection,

method injection, and an example of DI and unit testing, see the teacher's notes.

Dependency injection is a popular design pattern.

DI can be used with virtually any language or platform, with or

without the support of an external library.

Google's Angular framework and Microsoft's ASP.NET Core web framework,

as we'll see later in this workshop, provide built-in support for DI.

Unfortunately, the ASP.NET MVC web framework doesn't provide support for

DI out of the box.

You need to install and configure what's known as a DI container.

In the next video, we'll learn about DI containers and

select a DI container library to use in our project.