Service Lifetimes in ASP.NET Core: Transient vs Scoped vs Singleton

Introduction to Service Lifetimes in .NET

In ASP.NET Core, Dependency Injection (DI) is a powerful feature that helps developers build loosely coupled, testable, and maintainable applications. One key aspect of this system is understanding how services are managed over time, which is where Service Lifetimes come into play.

A Service Lifetime determines how long an instance of a service will live once it's created by the built-in IoC (Inversion of Control) container.

When a service is registered in the Program.cs (or Startup.cs in older versions), we must specify its lifetime. This decision directly affects.

• When the service instance is created
• How long will it be reused
• Whether it's shared across requests, users, or components

"How long will the instance of the service live?" and "When will a new instance be created?"

There are 3 built-in lifetimes.

Before diving into service lifetimes, it's very important to understand the core concepts.

• Dependency Injection (DI)
• Inversion of Control (IoC)

What is Dependency Injection (DI)?

Dependency Injection is a design pattern used to provide an object’s dependencies from the outside, instead of creating them inside the object itself.

Dependency = Another class or object that your class needs to function.

Injection = Supplying those dependencies externally.

Imagine you're a chef who needs ingredients to cook.

• Without DI, the chef goes out to the farm, harvests the vegetables, and then cooks.
• With DI, someone delivers the fresh ingredients to the chef so they can focus on cooking.

💡 DI = Someone gives you what you need. You don’t fetch it yourself.

🛑Without DI (tight coupling)

public class Car
{
    private Engine _engine = new Engine();  // Car creates its own engine

    public void Drive()
    {
        _engine.Start();
    }
}

Problem

• Hard to test
• Can’t swap the Engine with the electric engine easily
• Tight coupling

With DI (loose coupling)

public class Car
{
    private readonly IEngine _engine;

    public Car(IEngine engine)  // Engine is "injected" from outside
    {
        _engine = engine;
    }

    public void Drive()
    {
        _engine.Start();
    }
}

Now we can,

• Inject any IEngine implementation
• Test easily (mock the engine)
• Change logic without touching the Car class

What is Inversion of Control (IoC)?

Inversion of Control is a broader principle. It means that the control of creating and managing objects is inverted — from the class to a container or framework. In simpler terms.

Instead of our code controlling how things are created, the framework (like ASP.NET Core) does it for us.

Example of IoC

We register services in a container.

services.AddScoped<ICarService, CarService>();

Then our controller.

public class HomeController : Controller
{
    private readonly ICarService _carService;

    public HomeController(ICarService carService) // Injected by framework
    {
        _carService = carService;
    }
}

We didn’t create CarService — the IoC container did and gave it to us!

Relationship Between DI and IoC

So, Dependency Injection is a technique used to achieve Inversion of Control.

• IoC: Framework creates and manages the object
• DI: The Controller gets the service it needs without creating it

Why Are Service Lifetimes Important?

Choosing the correct service lifetime is essential for,

builder.Services.AddTransient<IMyService, MyService>();   // Transient
builder.Services.AddScoped<IMyService, MyService>();      // Scoped
builder.Services.AddSingleton<IMyService, MyService>();   // Singleton