What is Inversion of Control (IoC)?
Quick Answer
Inversion of Control is a principle where the flow of control — who creates objects, who calls whom — is handed to a framework or container instead of your own code. Dependency Injection is one form of IoC: your class no longer decides which implementation to create, the container does. The framework calls your code, not the other way round (“don't call us, we'll call you”).
Inversion of Control means giving up control of object creation and program flow to a framework. Normally my code decides what to instantiate and in what order things run. With IoC, the container or framework does that — I just provide the pieces. Dependency Injection is the most common example: I declare that I need an IEmployeeService, and the container decides which implementation to build and when. The ASP.NET Core pipeline is another example — I don't invoke the framework, it invokes my controller action when a route matches. The phrase people use is “don't call us, we'll call you.”
In traditional code, your code is in charge: it creates objects, decides which concrete class to use, and drives the sequence of calls. With IoC, that responsibility is inverted to a framework.
You see IoC in several places:
- Dependency Injection — the container creates dependencies and injects them; your class just declares what it needs.
- The ASP.NET Core framework itself — you don't call the framework to handle a request; it calls your controller action when a route matches.
- Event handlers and callbacks — you register a method; the runtime decides when to call it.
- Template method pattern — the base class controls the algorithm and calls your override at the right point.
IoC vs DI. IoC is the broad principle. DI is a specific technique for achieving it, focused on how a class gets its dependencies. An “IoC container” and a “DI container” are the same thing in .NET conversation. The Dependency Inversion Principle (the D in SOLID) is related but different — it says high-level modules and low-level modules should both depend on abstractions.
Practise the whole thread the way an interviewer walks it — each question builds on the last.