Dependency Injection Internals

Every ASP.NET Core developer uses builder.Services.AddScoped<...>(), but few understand what happens inside the Inversion of Control (IoC) Container. To master C# architecture, you must understand how the container uses Reflection and Service Lifetimes to manage the memory and disposal of your entire application graph.

1. The Three Lifetimes

Choosing the wrong lifetime is the #1 cause of memory leaks and captive dependencies in production.

• Transient: A brand new instance is created every time it's requested. (Lightweight, stateless).
• Scoped: One instance is created per HTTP Request. Shared across all classes in that request.
• Singleton: Exactly ONE instance is created for the entire life of the application. (Stateful, must be thread-safe).

2. How the Container Resolves Types

The container is essentially a giant Dictionary<Type, ServiceDescriptor>. When you ask for an IUserService, the container:

1. Looks up the implementation type (UserService).
2. Uses Reflection to find its constructor.
3. Recursively resolves every parameter in that constructor.
4. Instantiates the object and handles the lifecycle.

3. Captive Dependencies

This happens when a Singleton service mistakenly tries to inject a Scoped service. Because the Singleton never dies, it "captures" the Scoped service, keeping it alive for the entire app life. This can lead to database connection leaks or stale user data appearing for the wrong person!

4. Interview Mastery

Q: "Why should we prefer Constructor Injection over the Service Locator pattern (`serviceProvider.GetService()`)?"

Architect Answer: "Service Locator is considered an Anti-Pattern because it hides the dependencies of a class. When you use Constructor Injection, you are declaring: 'I cannot function without these 3 services.' This makes the code self-documenting and incredibly easy to Unit Test (you just pass mocks). If you use a Service Locator, the class 'lies' about its dependencies, hides its requirements inside method bodies, and becomes almost impossible to test without mocking the entire underlying .NET service provider architecture."