What is dependency injection, what problem does it solve, and how do you register and inject a service?

Say it out loud, then check

One request, start to end

Every idea on this card in one flow: routing, the scope, registrations, building bottom-up, injecting, running, and clean-up.

The story

1. Before

   In older code, and in many .NET Framework apps, each class built what it needed. LoanService held new LoanRepository(), and the repository held new ServicingDbContext(). Each class quietly chose its own parts.

2. Why it had to change

   Nobody could test LoanService without a real database. Changing the repository, or even its connection string, meant finding and editing every new, and missing one meant a bug.

3. How it works now

   Now each class lists its needs in its constructor, and the container builds the whole chain for every request. The storyboard follows one request from start to end.

4. What happens next

   Program.cs is the one place that says which class fills each need. The controller, the service and the repository never call new on each other.

5. What we gained

   Unit tests with fakes. One-line swaps. Needs you can read from the constructor. Lifetimes and disposal handled by the container. And ValidateOnBuild checks the wiring before the app takes traffic.

In the lending API

LoanService after the fix. It never builds its repository; it receives one in its constructor.

Only the key lines are shown; Deep walks the whole file.

The code, file by file

Slice 1 of the lending API: one request for one loan, from Program.cs down to the repository, then the unit test DI makes possible. Before tabs first, then the fixed files.

What they ask next

The follow-ups interviews really ask. Answer out loud, then tap to check.

• ReportedHow do you implement DI in a controller?

  Constructor injection. The controller takes ILoanService in its constructor and keeps it in a readonly field. Program.cs registers ILoanService, and AddControllers turns on controllers. I never write new for the controller or the service.

  public LoansController(ILoanService loans)
    => _loans = loans;

  Next questions, in Deep →Where this was reported
• ReportedWhy is it better to inject dependencies instead of creating them?

  Four reasons. I can unit test a class by passing in fakes. I can swap an implementation by changing one line in Program.cs. A class's needs are visible in its constructor. And the container handles lifetimes and disposal, so no class has to.

  Next questions, in Deep →Where this was reported
• ReportedWhy do we register services in Program.cs?

  Program.cs runs once at start-up and is the one place where the app is wired together. People call it the composition root. Registering only writes the list; builder.Build() turns it into the container, and objects are built later, when a request asks for them.

  Next questions, in Deep →Where this was reported

Follow-up tree

Answer, then open the next level. That is the order an interviewer digs in.

Reporteda candidate was asked Intervieweran interviewer asks it

• ReportedHow do you implement DI in a controller?

  Constructor injection. The controller takes ILoanService in its constructor and keeps it in a readonly field. Program.cs registers ILoanService, and AddControllers turns on controllers. I never write new for the controller or the service.

  public LoansController(ILoanService loans)
    => _loans = loans;

  Where this was reported
  • When exactly is the controller instance created?

    Once per request, after routing has picked the action. ASP.NET Core builds it with that request's scope, so it gets that request's scoped services, and it is thrown away when the request ends. Controllers are not in the container's list by default; AddControllersAsServices puts them there. The storyboard shows each step.

  • ReportedWhat are the different ways to inject a service?

    Constructor injection is the default. Method injection: one action asks for a service with [FromServices], or a minimal API handler simply lists it as a parameter. Middleware gets per-request services as InvokeAsync parameters. You can also ask HttpContext.RequestServices by hand, but that hides the need, so it is a last resort. The built-in container has no property injection; Autofac adds it.

    public IActionResult Statement(
      Guid id,
      [FromServices] IStatementPdf pdf)
      => File(pdf.Build(id), "application/pdf");

    Where this was reported
• ReportedWhy is it better to inject dependencies instead of creating them?

  Four reasons. I can unit test a class by passing in fakes. I can swap an implementation by changing one line in Program.cs. A class's needs are visible in its constructor. And the container handles lifetimes and disposal, so no class has to.

  Where this was reported
  • ReportedWhat is IoC, and how is it different from DI?

    Inversion of control is the general idea: your class stops controlling something, here how its parts are built, and a framework does it instead. DI is one way to do that. The Dependency Inversion Principle, the D in SOLID, is a design rule: high-level code like LoanService depends on an abstraction like ILoanRepository, not on the SQL class. DI is how that abstraction gets supplied.

    Where this was reported
  • Isn't passing IServiceProvider in and asking it for things the same?

    No. That is the service locator pattern: the constructor no longer shows what the class needs, and a missing registration fails deep inside a method. The resolving page shows that bug.

  • Is DI inheritance or composition?

    Composition. LoanService has a repository; it is not a kind of repository. DI is composition where someone else picks and passes in the part: see composition.

• ReportedWhy do we register services in Program.cs?

  Program.cs runs once at start-up and is the one place where the app is wired together. People call it the composition root. Registering only writes the list; builder.Build() turns it into the container, and objects are built later, when a request asks for them.

  Where this was reported
  • ReportedWhat does AddScoped do?

    It registers a service with one object per request: every class in that request shares it. The three lifetimes and how to pick one are on the lifetimes card.

    Where this was reported
  • What happens if you forget a registration?

    It still compiles, then fails at run time with "Unable to resolve service for type…". See the first production bug below; ValidateOnBuild moves the failure to start-up.

• A constructor needs too many dependencies. Which SOLID principle is broken, and why is readonly preferred?

  Too many parameters, say eight, usually means the class has several jobs: that breaks the Single Responsibility Principle: one class, one job. I split it by job, for example payments and statements into their own services. DI didn't cause the problem; it made it visible. readonly means the field can only be set in the constructor, so nobody can replace or null the dependency later.

  // Smell: one class, many jobs
  public LoanService(ILoanRepository loans,
    IPaymentGateway pay, IStatementPdf pdf,
    ISmsSender sms, ICreditBureauClient cb,
    ICountryRules rules, TimeProvider clock,
    ILogger<LoanService> log)

• How was DI different in .NET Framework?

  ASP.NET MVC 5 and Web API 2 had no container built in. Teams added Autofac, Unity or Ninject and plugged it in through DependencyResolver. ASP.NET Core has one built in from the start, and the framework itself (logging, options, EF Core) uses it. You can still plug Autofac in when you need extras like property injection or modules.

Production bugs, and how to tell them

Each one: what you see, why, the fix in code, and the line to say.

• Unable to resolve service: a registration line is missing

  $ curl https://localhost:5001/api/loans/7
  HTTP/1.1 500 Internal Server Error
  
  System.InvalidOperationException: Unable to resolve service for type 'Lending.Application.Servicing.Loans.ILoanRepository' while attempting to activate 'Lending.Application.Servicing.Loans.LoanService'.

  Cause

  LoanService asks for ILoanRepository in its constructor, but Program.cs has no line for it. It compiles, because the list is only read when the app runs, never by the compiler.

  Fix

  Add AddScoped<ILoanRepository, LoanRepository>(), and turn on ValidateOnBuild so the next missing line stops the app at start-up instead of on a customer's request.

  BeforeAfter

  1var cs = builder.Configuration2 .GetConnectionString("Lending");3builder.Services.AddDbContext<4 ServicingDbContext>(o =>5 o.UseSqlServer(cs));6builder.Services.AddScoped<7 ILoanService, LoanService>();8// ILoanRepository: never registered9 10var app = builder.Build();

  Before · Program.cs · line 7 · 1 of 2LoanService is registered, but what it needs is not. Nothing complains until a request asks for it.

  BackNext line

  Say it

  The container only knows what Program.cs tells it. A missing registration compiles and fails at run time, on the first request that needs it. We switch on ValidateOnBuild, which checks registered services at start-up, and a CI test starts the app with WebApplicationFactory, so it fails in the pipeline, not in production.

• A test passes in October and fails in November

  $ dotnet test
    Failed LoanServiceTests.Due_1_Nov_is_not_overdue
    Assert.False() Failure
    Expected: False
    Actual:   True

  Cause

  IsOverdue read DateTime.UtcNow inside the method. Time was a dependency the class never listed, so the test couldn't control it.

  Fix

  Inject TimeProvider. The app registers TimeProvider.System; the test passes a FakeTimeProvider set to a fixed date.

  BeforeBeforeAfterAfter

  Diagram · step 2IsOverdue reads the real clock inside the method. The test can't set the date.Show diagram

  Test: not overdue

  Oct: pass

  LoanServiceIsOverdue

  DateTime.UtcNowthe real clock

  1public bool IsOverdue(Loan loan) =>2 loan.NextDueDate < DateOnly.FromDateTime(3 DateTime.UtcNow);

  Before · LoanService.cs · line 3 · 1 of 1The real clock, read inside the method. Nothing outside can change it.

  BackNext file

  Say it

  Anything a class reads from outside is a dependency, including the clock. When a test depends on today's date, I inject TimeProvider, so the test sets the time and gives the same result every day.

Traps

• Don't sayDI means using a container.SayDI is passing a class its dependencies from outside. The container only automates it: new LoanService(fakeRepo) in a test is DI too.
• Don't sayYou need an interface for everything you inject.SayThe container injects classes too, like ServicingDbContext or TimeProvider. I add an interface where I want to swap the implementation.
• Don't sayRegistering a service in Program.cs creates it.SayRegistering writes one row in a list. The object is built later, when something asks for it.
• Don't sayI inject IServiceProvider and get what I need.SayThat is a service locator: it hides the class's needs and fails late. Every need goes in the constructor.
• Don't sayDI is only for testing.SayTesting is one gain. The others are one place to swap implementations and the container managing lifetimes and disposal.

Traps

What should you say instead? Tap to check.

• Don't sayDI means using a container.

  Say instead

  DI is passing a class its dependencies from outside. The container only automates it: new LoanService(fakeRepo) in a test is DI too.

• Don't sayYou need an interface for everything you inject.

  Say instead

  The container injects classes too, like ServicingDbContext or TimeProvider. I add an interface where I want to swap the implementation.

• Don't sayRegistering a service in Program.cs creates it.

  Say instead

  Registering writes one row in a list. The object is built later, when something asks for it.

• Don't sayI inject IServiceProvider and get what I need.

  Say instead

  That is a service locator: it hides the class's needs and fails late. Every need goes in the constructor.

• Don't sayDI is only for testing.

  Say instead

  Testing is one gain. The others are one place to swap implementations and the container managing lifetimes and disposal.