Learn how the IoC Container and dependency injection work in C# and ASP.NET

Dependency Injection

Let's begin by implementing the Dependency Inversion Principle: our class should depend on an abstraction (i.e. interface).

An interface does not define any method bodies, but it forces any class implementing the interface to define them. If we make our class depend on an interface, then the dependency's method body can change without breaking our class.

In our example, if we use an `ISpeaker` interface, we can make changes to the `LoudSpeaker` class as long as it still implements the interface. If it does, we don't have to touch the `Trainer` class to handle the changes.


 Abstract the Dependency

Let's now implement the Inversion of Control Principle: Don't call us, we'll call you.

In our specific project, it means that the Trainer class should not instantiate any dependency: `LoudSpeaker` or `QuietSpeaker`. It should only declare a dependency, and the actual class will be instantiated elsewhere and inserted into the Trainer class.

We'll do this using _dependency injection_. Dependency injection is the actual insertion of the object. It can be done in a lot of ways, but we'll focus on one type of dependency injection called constructor injection because it's the most commonly used in the ASP.NET framework.


Here's a common example, you might find inside **IndexModel.cshtml.cs**:
```cs
private static readonly ILogger _logger;
public void IndexModel(ILogger logger)
{
  _logger = logger;
}
```

In this example, `IndexModel` depends on some logging class. It declares its dependency in the form of an interface, `ILogger`. It never instantiates an actual class though. Somewhere else in the code, a `Logger` object is constructed and passed (or injected) into the `IndexModel`:
```cs
IndexModel i = new IndexModel(new Logger());
```


(Some examples here don't match the exact code you'd find in ASP.NET applications; they'll be simplified so that we can focus on the subject of dependencies.)


 Inject the Dependency

You've seen where the dependency will be injected, but you haven't seen how it actually happens. You might think that we do it like before:
```cs
new IndexModel(new Logger());
````

We won't need to type this because it is all handled by ASP.NET's IoC container. In a  basic ASP.NET application, you're not really going to see that code at all.

Instead of the above code, all we have to do is register the services that will act as dependencies, so that the container knows what to inject when a page model asks for them.

We do this in `ConfigureServices()`:

```cs
ConfigureServices(IServiceProvider services)
{
  services.AddScoped<ISomething, Something>();
}
```

In the above code we are saying: "Hey IoC container, whenever a class asks for an `ISomething` service, inject a `Something` instance into it". We'll explain `AddScoped()` in a few exercises.

Then we can request that service in our page models:

```cs
private readonly ISomething _something;
public IndexModel(ISomething something)
{
  _something = something;
}
```

This approach to dependency injection makes the Dependency Inversion and Inversion of Control principles more obvious:
* Modules should depend on abstractions: the page model only references an interface, i.e. an abstraction.
* Don't call us, we'll call you: we never see the service object instantiated or passed into a constructor. All of that is handled by the framework.


 Injection in ASP.NET

In the past exercise, we registered a service with the method `AddScoped()`. Each service has a "lifetime" and we wanted our service to have a lifetime "scoped to each user". This lesson won't get too deep into the details; you just need to know that there are three lifetime options:

* `AddScoped<T1, T2>()` - the service class is instantiated once per user, across the web app.
* `AddTransient<T1, T2>()` - the service class is instantiated every time it is requested.
* `AddSingleton<T1, T2>()` - the service class is instantiated once. That object is used throughout the web app, and across users.

In general, you use them like so:
```cs
public void ConfigureServices(IServiceProvider services)
{
  services.AddScoped<IAccount, CustomerAccount>();
  services.AddTransient<IResponder, Responder>();
  services.AddSingleton<ILogger, Logger>();
}
```

By the way, when we say "register" we mean "register an abstraction and its implementation with the IoC Container so that other classes can access the implementation via dependency injection".


 Registering other services

Whew! You made it through a lot of content. Let's review:
* _Dependencies_ in our code can cause problems, like:
  * The codebase is harder to maintain
  * We can't test classes individually
  * The system isn't flexible enough to allow us to swap the dependency for something similar
* The _Dependency Inversion Principle_ (DIP) attempts to resolve theses dependency problems by the use of abstraction:
  * "High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g. interfaces)."
  * "Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions."
* _Inversion of Control_ (IoC) is a programming principle that attempts to resolve the dependency problems by giving control to the framework, rather than the dependent class:
  * "Methods defined by the user should be called from within the framework itself, rather than from the user's application code"
* To apply these principles in our code, we use interfaces and _dependency injection_
* There are many ways to inject but we used _constructor injection_
* To do all of this in ASP.NET, we can use the provided _IoC container_
* We register services with the container by adding "AddX" methods to `Startup.ConfigureServices()`
* We can register built-in services, like database context, with built-in methods, like:
```cs
public void ConfigureServices(IServiceCollection services)
{
  services.AddRazorPages();
  services.AddDbContext<SomeContext>();
}
```
* We can access some default-registered services, like `ILogger<T>`, without registering additional services
* We can register custom services, with "AddX" methods, like
```cs
public void ConfigureServices(IServiceProvider services)
{
  services.AddScoped<IAccount, CustomerAccount>();
  services.AddTransient<IResponder, Responder>();
  services.AddSingleton<ILogger, Logger>();
}
```
 
Sometimes programming principles can feel hard to grasp without actual examples. We provided some in this lesson, but you can find more in these sources:
* ["Dependency injection in ASP.NET Core", Microsoft](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection) 
* ["Understanding Dependency Injection in .NET Core", Auth0](https://auth0.com/blog/dependency-injection-in-dotnet-core/#L-NET-Core-and-the-Dependency-Injection)


Review

There are some common services that the ASP.NET framework has made easy-to-register by providing unique AddX methods. You might recognize:

```cs
public void ConfigureServices(IServiceCollection services)
{
  services.AddRazorPages();

  services.AddDbContext<CountryContext>(options =>
    options.UseSqlServer(Configuration.GetConnectionString("CountryContext")));
}
```

The `AddRazorPages()` method allows us to use page model features and the `AddDbContext<T>()` connect our app to a database. In our page model constructor, we can access the database service like so:

```cs
public class IndexModel : PageModel
{
  private readonly CountryContext _context;

  public IndexModel(CountryContext context)
  {
    _context = context;
  }

  public IList<Country> Country { get;set; }

  public async Task OnGetAsync()
  {
    Country = await _context.Country.ToListAsync();
  }
}
```

Note that this is one exception to the Dependency Inversion Principle: we depend on the class `CountryContext` instead of an interface because our app relies specifically on this type.

There are more common services that ASP.NET just assumes you need, such as `ILogger` services. You don't even need to register these in `ConfigureServices()`. Those are registered automatically\*. We can just request them in the page model:


```cs
public class PrivacyModel : PageModel
{
  private readonly ILogger<PrivacyModel> _logger;

  public PrivacyModel(ILogger<PrivacyModel> logger)
  {
    _logger = logger;
  }
}
```

\* Those "automatically" registered services are actually determined by the host type, which is defined in **Program.cs**. For more information, visit the [Microsoft documentation](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/host/generic-host).


 Built-in Services

We're introducing a lot of terms here, so for recap: 
* The _Dependency Inversion Principle_ (DIP) attempts to define and resolve the dependency problem through use of abstraction (interfaces). 
* The _Inversion of Control_ principle attempts to resolve the dependency problem by moving control of dependencies to a separate class.
* _Dependency Injection_ is one of many design patterns that implements the IoC principle.

Let's try to put it all together. In the code editor, you can see that the original version of `Trainer` is already in the code. We'll update it to use the new version.


 Test it out in Program.cs

Here's one problem with this situation: if the dependency changes, we also have to change the dependent class. This means that:
* The code base is harder to maintain.
* We can't test classes individually (if we change `LoudSpeaker`, then the `Trainer`'s behavior will change even though we didn't change any code in that class).
* The system isn't flexible enough to allow us to swap the dependency for something similar.


 Dependency Problems

Before we get into ASP.NET, let's take a look at a basic dependency in C#.

In this program we have two important classes:
* `Trainer`
* `LoudSpeaker`

In order to work correctly, the `Trainer` class needs a `LoudSpeaker` instance. Thus `LoudSpeaker` will be a dependency for the `Trainer` class. 


Dependencies

Well done! You've learned how to apply the DIP and IoC principles. So how does this factor into ASP.NET development?

If you've ever logged information or added a database in your application, you've already used these principles!
Within Razor Pages, each page model depends on certain tools, such as loggers, databases, and authentication tools. We call these tools _services_.
 
Instead of instantiating the relevant objects and injecting them ourselves, ASP.NET gives us a built-in feature to do it for us, called an IoC container or DI container (Inversion of control and Dependency Injection, respectively).

Each page model "requests" and accesses services by listing them in its constructor. Here's an example...

```cs
public class IndexModel : PageModel
{
  private readonly IService service;

  public IndexModel(IService _service)
  {
    service = _service;
  }
}
```


The interface `IService` here is the service. The IoC container will eventually provide an object that fulfills that service (in other words, an object that implements the interface).


 Applying DI to ASP.NET

Now that you've seen dependencies, imagine a codebase full of these dependent classes. Now imagine that the dependencies ALSO have dependencies. One change in one dependency could break dozens of other classes. It gets messy very quickly.

In the early 2000s, the influential developers and authors Robert C. Martin and Martin Fowler came up with a strategy to resolve these problems. They generalized their strategy into two principles.

The first principle is the [Dependency Inversion Principle](https://en.wikipedia.org/wiki/Dependency_inversion_principle) and it states:
* High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g. interfaces).
* Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.

In our previous example, the `Trainer` class depended on the `LoudSpeaker` class. The Dependency Inversion Principle (DIP) states that the `Trainer` class should depend on some `ISpeaker` interface. `LoudSpeaker` should be designed to implement that interface.

The second principle is the [Inversion of Control Principle](https://en.wikipedia.org/wiki/Inversion_of_control) and it states:
* Methods defined by the user should be called from within the framework itself, rather than from the user's application code

This is also known as the "Hollywood Principle": Don't call us, we'll call you.

In our previous example, the `Trainer` class should not instantiate another class. It may declare a certain dependency and some other part of the program will provide and manage that dependency.



First, Component 1 depends on Component 2.

Second, Component 1 refers to Interface and Component 2 implements Interface.

Principles to Solve the Problems

You may have noticed that ASP.NET apps aren't built from the ground up. We rely on other programmers' existing code to get started and quickly add new features. For example, think how little code we need to add a database to a web app. 

When we rely on other programmer's code, we say that our code has _dependencies_. Our code _depends_ on other code. We can do a lot with dependencies, but they also add a new set of problems. Dependencies make our code:
* Difficult to unit test
* Difficult to update
* Messy, i.e. responsibilities of classes are mixed

In this lesson, we are going to better understand those problems, learn about some design principles that avoid those problems, and finally look at some tools in ASP.NET that employ those principles.

By the end of this lesson you will be able to:
* Define the dependency inversion and inversion of control principles
* Define dependency injection and describe its benefits
* Use basic dependency injection in C#
* Use the dependency injection and the IoC container in ASP.NET
