Dependency Injection vs Service Locator

What is Dependency Injection?

Dependency Injection is a technique in which a component receives the objects it depends on rather than creating them itself. The most common form is constructor injection: every required dependency is listed as a constructor parameter. When something wants to create the component, it must supply those dependencies — and the component is then fully initialised and ready to use.

This approach follows the Explicit Dependencies Principle: a method or class should honestly declare all the things it requires to do its job. Constructor injection makes this requirement part of the type signature, so violations are caught by the compiler or at application startup rather than in production.

A DI container (also called an IoC container) automates the wiring. You register your types once at the composition root — the single point where the object graph is assembled — and the container resolves the full dependency tree for you. Spring's ApplicationContext, .NET's IServiceCollection, and Angular's hierarchical injector are all examples of DI containers.

{`// Dependencies declared in the constructor signature.
// Any caller must supply them — nothing is hidden.
class OrderService {
  constructor(
    private readonly orderRepo: IOrderRepository,
    private readonly emailService: IEmailService,
    private readonly logger: ILogger,
  ) {}

  async placeOrder(cart: Cart): Promise<Order> {
    const order = await this.orderRepo.save(cart);
    await this.emailService.sendConfirmation(order);
    this.logger.info('Order placed', { id: order.id });
    return order;
  }
}

// Unit test — pass mocks directly, no global setup
const svc = new OrderService(
  mockRepo, mockEmail, mockLogger,
);`}

{`// NestJS uses TypeScript decorators
// and a module-level DI container.
import { Injectable } from '@nestjs/common';

@Injectable()
export class OrderService {
  constructor(
    private readonly orderRepo: OrderRepository,
    private readonly emailService: EmailService,
  ) {}

  async placeOrder(cart: Cart): Promise<Order> {
    const order = await this.orderRepo.save(cart);
    await this.emailService.sendConfirmation(order);
    return order;
  }
}
// The container resolves OrderRepository
// and EmailService automatically.`}

What is Service Locator?

The Service Locator pattern uses a central registry that components can query to retrieve their dependencies by name or type. Rather than being given its dependencies, a component calls the locator — typically a singleton — and asks for what it needs.

The pattern became well-known through Mark Seemann's 2010 post "Service Locator is an Anti-Pattern", which argued that it violates the Explicit Dependencies Principle and should generally be avoided in application code. His argument: the locator makes dependencies invisible, so the class's public interface lies about what it needs.

However, Service Locator is not universally wrong. Frameworks themselves often use a registry internally. Plugin systems — where one module must discover services registered by another module it was not compiled against — have a genuine need for runtime lookup. The key distinction is whether consuming application code calls the locator directly.

{`// Dependencies fetched from a global registry
// inside the method — hidden from the caller.
class OrderService {
  async placeOrder(cart: Cart): Promise<Order> {
    const repo = ServiceLocator
      .get<IOrderRepository>('OrderRepository');
    const email = ServiceLocator
      .get<IEmailService>('EmailService');
    const logger = ServiceLocator
      .get<ILogger>('Logger');

    const order = await repo.save(cart);
    await email.sendConfirmation(order);
    logger.info('Order placed', { id: order.id });
    return order;
  }
}

// Test: must configure the registry first
ServiceLocator.register('OrderRepository', mockRepo);
ServiceLocator.register('EmailService', mockEmail);`}

{`// A minimal Service Locator implementation
public class ServiceLocator {
  private static final Map<Class<?>, Object>
    registry = new HashMap<>();

  public static <T> void register(
    Class<T> type, T impl) {
    registry.put(type, impl);
  }

  @SuppressWarnings("unchecked")
  public static <T> T resolve(Class<T> type) {
    T svc = (T) registry.get(type);
    if (svc == null) throw new RuntimeException(
      "No registration for " + type.getName());
    return svc;
  }
}

// Usage (inside a component — avoid this)
IOrderRepository repo =
  ServiceLocator.resolve(IOrderRepository.class);`}

Spring vs Angular DI — two mainstream approaches

Both Spring (Java/Kotlin) and Angular (TypeScript) are built on the DI principle but implement it differently.

Spring uses annotations on classes (@Component, @Service, @Repository) and injection points (@Autowired, constructor injection). The Spring ApplicationContext scans the classpath, builds a bean registry, and resolves the dependency graph at startup. Spring Boot's auto-configuration reduces boilerplate significantly.

Angular uses a hierarchical injector that mirrors the component tree. Each @NgModule and each component can provide its own injector scope, so a service can be application-wide (provided in root) or scoped to a feature module. The @Injectable() decorator marks a class as injectable, and dependencies are declared in the constructor — same principle as constructor injection everywhere else.

The practical difference: Spring has a flat, application-wide container by default; Angular's hierarchy means a service instance can be shared across one subtree but not others — useful for feature-level state. If you work with either framework, understanding these differences matters for interviews and code reviews. See also TypeScript vs JavaScript for context on Angular's type system.

How engineers talk about DI vs Service Locator

These are the phrases you will hear in code reviews, architecture discussions, and technical interviews:

When to use each pattern

Use Dependency Injection when:

• Building application services, repositories, or controllers. Constructor injection makes requirements explicit, keeps components testable, and is what every major framework expects.
• You want fast, isolated unit tests. Pass a mock directly via the constructor — no global state, no configuration overhead.
• Using a DI framework. Spring, Angular, NestJS, and .NET's built-in container all prescribe constructor injection. Follow their conventions.
• You want compile-time or startup-time safety. Typed DI containers catch missing registrations before a request ever arrives, not in production at 3 am.
• Code readability matters. A constructor signature is a contract. Readers know immediately what a class needs without opening the body.

Service Locator may be appropriate when:

• Building a plugin or extension system. Plugins registered at runtime cannot be known at compile time; a registry is the natural solution.
• Working inside framework internals. The framework owns the registry and its consumers are carefully controlled — a different situation from application code.
• Migrating legacy code incrementally. Introducing a locator can be a transitional step away from new Dependency() calls everywhere — but treat it as temporary scaffolding, not a destination.

Quick decision guide

• Building a new service, repository, or controller → Constructor injection
• Need fast, isolated unit tests → Constructor injection
• Using Spring, NestJS, Angular, or .NET DI → follow the framework's DI conventions
• Seeing hidden dependencies inside method bodies → refactor to constructor injection
• Building a plugin system with runtime service discovery → Service Locator may be appropriate
• Legacy codebase full of new Dependency() calls → introduce a DI container incrementally
• Framework internals that own their registry → Service Locator is acceptable inside the framework boundary