User-821857111 posted
The main use of a DI container is to detach classes from concrete dependencies. This is particularly useful for automated unit testing.
Let's say that you have an MVC action method that relies on a class (GMailer) to send an email. The mailer class connects to Gmail and does its thing when its SendEmail method is called. All you want to test is that the action method actually calls
the SendEmail method. At the moment, when you instantiate the controller in your unit test and invoke the action method, the GMailer class will actually try to send an email, resulting in a relatively slow test, which may fail because the GMailer class (which
you aren't testing) cannot connect to Gmail for some reason.
So what you do instead is pass an abstraction to the method (usually an interface) representing the mailer class:
public interface IMailer
{
void SendMail(MailMessage msg);
}
In your application, you use a DI container to register the concrete type that this interface should resolve to at runtime:
services.AddTransient<IMailer, GMailer>(); // ASP.NET Core DI
or
container.Bind<IMailer>().To<GMailer>(); // Ninject example
But in your test project, you register a fake or mock type instead, which has a SendMail method that doesn't do anything at all.
