🎉 DI Lifetimes in .NET Explained Like a Party You Actually Want to Attend

If you’ve ever worked with .NET Dependency Injection, you’ve met these three characters:

Singleton, Scoped, and Transient.

At first, they sound harmless. Friendly, even.

And then one day your app throws a mysterious ObjectDisposedException, your logs start screaming, and you realize…

You invited the wrong lifetime to the party.

Let’s fix that. No boring textbook explanations. Just vibes, analogies, and fewer production bugs.

🎭 Meet the Three Guests

🏠 Singleton — “I live here now”

Only one instance for the whole application.

Created once.

Lives until the app shuts down.

Everyone shares it. Forever.

Think: the person who shows up early, takes the couch, and never leaves.

Good examples: Logger, Cache service, Configuration, HttpClient (or via a factory)

Singletons are great when something is:

Expensive to create

Thread-safe

Meant to be shared by everyone

🧳 Scoped — “I’m here for this request only”

Created once per HTTP request.

Shared inside that request.

Destroyed when the request ends.

Think: someone who comes for this party, helps clean up, and goes home.

Good examples: DbContext, Repositories, Business services, Current user / request context

Important detail:

Scoped is not per controller. It’s per request.

If Controller A and Controller B are part of the same request and both use the same scoped service — they get the same instance.

🐇 Transient — “I just popped in for a second”

New instance every time you ask for it.

Ask twice → you get two different objects.

No memory. No commitment.

Think: someone who shows up, says hi, disappears, and if you see them again… it’s basically a new person.

Good examples: Helpers, Mappers, Formatters, Small stateless utilities

If you inject a transient service twice in the same constructor:

Surprise! They are not the same object 😄

No more confusion. No more lifetime chaos. Now grab a slice 🍕 — the party’s just getting started.

Happy DI Pizza Party 🍕