Dependency inversion vs dependency injection vs IoC

Published 21 October 2026

The names are one word apart and both are shortened to "DI", so most people treat them as one thing. They answer two different questions.

Think of a cook in a restaurant kitchen. Dependency inversion is about the recipe: does it say "two spoons of any cooking oil", or "two spoons of one particular brand of sunflower oil"? Dependency injection is about the store room: is the oil handed to the cook, or does the cook leave the kitchen to buy it? A recipe can say "any oil" while the cook still goes shopping. And the store room can hand over exactly one brand to a recipe that only works with that brand.

• Dependency inversion (the D in SOLID) is a principle about types: business code depends on an abstraction, not on a concrete class.
• Dependency injection is a technique about creation: an object is given what it needs (usually through its constructor) instead of creating it.

Two questions, four answers#

Ask the two questions separately about any class and you get four combinations. Only one of them gives you both fast tests and a vendor switch that does not touch business code.

import { Razorpay } from './razorpay'

class OrderService {
  private gateway = new Razorpay('key_live_8f2a')
  checkout(rupees: number) {
    return this.gateway.charge(rupees)
  }
}

The dependency inversion chapter covers why the principle exists and draws the arrows before and after. This page is about telling it apart from the things it gets mixed up with.

Injection without inversion#

This is the most common version in real codebases, because frameworks make injection easy and say nothing about what type you inject:

class Razorpay {
  constructor(private key: string) {}
  charge(rupees: number) {
    return `razorpay ${rupees}`
  }
}
 
class OrderService {
  constructor(private gateway: Razorpay) {}
  checkout(rupees: number) {
    return this.gateway.charge(rupees)
  }
}
 
const fake = { charge: (rupees: number) => `fake ${rupees}` }
new OrderService(fake)
// Error: Property 'key' is missing in type

The gateway is passed in, so it is injected. But OrderService still names Razorpay. The fake has the right charge method and TypeScript still rejects it, because Razorpay has a private field and a class with private members only accepts its own instances (or subclasses). Your test now has to extend Razorpay and work around its constructor, and a Paytm can never be passed in at all.

Inversion without injection#

The opposite also exists. Here OrderService names only the interface, but goes and fetches the real object itself from a shared registry. That is called a service locator:

interface PaymentGateway {
  charge(rupees: number): string
}
 
const registry = new Map<string, PaymentGateway>()
registry.set('payments', { charge: (r) => `razorpay ${r}` })
 
class OrderService {
  // Names only the interface, but fetches the object itself.
  private gateway = registry.get('payments')!
  checkout(rupees: number) {
    return this.gateway.charge(rupees)
  }
}
 
console.log(new OrderService().checkout(300)) // razorpay 300

It does depend on an abstraction, and you can swap gateways by changing the registry. The cost is that the dependency is hidden: new OrderService() takes no arguments, so nothing tells you it needs a payment gateway until it fails at runtime with nothing registered. Every test has to remember to fill in the global registry first, and two tests running in parallel can step on each other's entries. Most teams treat service locator as something to move away from.

Both: the version to aim for#

Ask for the interface in the constructor, and create the real objects in one place at the edge of the app. That place is often called the composition root: main.ts, the server start file, or a module's setup function.

interface PaymentGateway {
  charge(rupees: number): string
}
 
class Razorpay implements PaymentGateway {
  constructor(private key: string) {}
  charge(rupees: number) {
    return `razorpay ${rupees}`
  }
}
 
class OrderService {
  constructor(private gateway: PaymentGateway) {}
  checkout(rupees: number) {
    return this.gateway.charge(rupees)
  }
}
 
// main.ts: the one place that knows the real classes
const orders = new OrderService(new Razorpay('key_live_8f2a'))
console.log(orders.checkout(499)) // razorpay 499
 
// order-service.test.ts: a fake is a plain object
const charged: number[] = []
const fake: PaymentGateway = {
  charge: (rupees) => {
    charged.push(rupees)
    return 'ok'
  },
}
new OrderService(fake).checkout(120)
console.log(charged) // [ 120 ]

OrderService does not know Razorpay exists. Its constructor lists exactly what it needs. The test needs no network, no subclass and no global setup.

Where IoC and containers fit#

Two more terms join this pair in interviews.

Inversion of control (IoC) is the broadest idea: instead of your code calling a library, a framework calls your code. Express calls your route handler, React calls your component, a test runner calls your test. The usual summary is "don't call us, we'll call you". Dependency injection is one kind of inversion of control, where control over creating dependencies moves out of the class.

A DI container is a tool that does the wiring in the composition root for you. You register which class to use for each dependency, and it builds the whole graph. NestJS and Angular have one built in, and InversifyJS and tsyringe are standalone ones for TypeScript.

You do not need a container to do injection. Wiring by hand in one file is plain code that anyone can read and step through in a debugger. Many teams only reach for a container once the composition root has dozens of services and the hand wiring is a page long.

In the interview#

Checkpoint#