How I Started Seeing Dependency Injection a Bit Differently 😊🍺

Source: Dev.to

Dependency Injection (DI): It’s Not Just About Clean Code—It’s About Saving Server Costs

1. The Anatomy of a Request: “The Object Cluster”

To process a request, the application creates a “cluster of objects” linked together in a chain:

• Controller – entry point for the request.
• Services – contain business logic.
• Repositories, Logging, and Database Contexts – handle data access and diagnostics.

This is the core of OOP: everything is transformed into an object to be processed. Once the task is done, the cluster is disposed of.

2. The RAM Nightmare and the Birth of DI

DI was born to address the RAM‑intensive nature of object clusters. While popularized by industry giants like Martin Fowler and Robert C. Martin (Uncle Bob), in the .NET world it has become the “heart” that regulates the lifetime of these objects.

3. The “Life & Death” Coordinator: Singleton, Scoped, and Transient

• Transient (Short‑Lived) – Created every time they are requested. Think of them like a paper napkin—use once and throw away. Best for lightweight, stateless logic.
• Scoped (Request‑Lived) – One instance is shared across the entire cluster for a single HttpContext. When the request finishes, its role ends. This is a massive RAM saver because we don’t recreate the same service multiple times within one thread.
• Singleton (Long‑Lived) – Created once when the app starts and lives until it shuts down. This is the “Big Boss” shared by millions of requests. It’s the ultimate resource saver, though it requires careful handling of data concurrency.

4. The Other Side of the Coin: Decoupling

Thanks for reading my take on DI. This is my first time writing about this, so if you have a different perspective or see any gaps, I’d love to hear your thoughts in the comments! Let’s share and learn together. 🍻