All 10 Dependency Injection & IoC Principles questions
More in Dependency Injection & IoC Principles
How do you register and resolve a service using ASP.NET Core's built-in dependency injection container? What is the difference between Singleton, Scoped, and Transient service lifetimes in ASP.NET Core's DI container? What is the Inversion of Control (IoC) principle, and how does dependency injection relate to it as one specific technique? How does constructor injection differ from property (setter) injection, and why is constructor injection generally preferred? What causes a 'captive dependency' bug, and how does ASP.NET Core's DI container detect and prevent it? How would you implement the Factory pattern using dependency injection to resolve a specific implementation at runtime based on a parameter, when the standard container can't decide statically? How do you correctly and safely resolve a Scoped service from within a Singleton service using IServiceScopeFactory, avoiding the captive dependency problem? How would you write a custom IServiceProviderFactory or use a third-party container (like Autofac) to enable advanced DI features not supported by the built-in ASP.NET Core container, like property injection or convention-based registration? How does the DI container resolve a class with MULTIPLE constructors, and how do you influence which one gets chosen?
Advertisement
Back to results for “Interfaces & Abstract Classes”
C# › Dependency Injection & IoC Principles

What is dependency injection, and what problem does it solve compared to a class creating its own dependencies directly?

Beginner

Answer

Dependency injection means a class RECEIVES its dependencies (typically via constructor parameters) from an external source, rather than constructing them itself with 'new' — this decouples the class from specific implementations, making it far easier to swap implementations (like for testing) and centralizing how objects get wired together.
// Without DI: tightly coupled, hard to test
public class OrderService {
  private readonly SqlDatabase _db = new SqlDatabase(); // hardcoded dependency
}

// With DI: loosely coupled, testable
public class OrderService {
  private readonly IDatabase _db;
  public OrderService(IDatabase db) { _db = db; } // injected
}
Real-world example Making a service class testable by injecting a fake/mock database implementation instead of a real SQL connection during unit tests.

Common follow-ups: What are the three common forms of dependency injection: constructor, property, and method injection?

Interfaces & Abstract Classes
All 10 Dependency Injection & IoC Principles questions