Service Locator Vs Dependency Injection - Learning Module

Loading content...

0/246

When Service Locator Is Acceptable

Beyond Dogma: Contextual Decisions

We've established that Service Locator is generally an anti-pattern that creates significant problems. However, experienced engineers don't follow rules blindly—they understand why rules exist and when exceptions are justified.

There are genuine scenarios where Service Locator's costs are worth accepting, where Dependency Injection's benefits don't fully apply, or where practical constraints make Service Locator the pragmatic choice. Recognizing these scenarios demonstrates mature engineering judgment: the ability to choose the right tool for the context rather than applying patterns dogmatically.

What You Will Learn

By the end of this page, you will understand the legitimate use cases for Service Locator, how to evaluate tradeoffs in specific contexts, and how to mitigate Service Locator's problems when you must use it. You'll develop nuanced judgment that goes beyond 'always use DI, never use Service Locator.'

Framework and Infrastructure Code

The strongest case for Service Locator is in framework and infrastructure code—code that must work without controlling how objects are created. When you're building a framework that other developers use, you often cannot inject dependencies into their classes.

The key insight: Dependency Injection works beautifully when you control object creation (composition root). But framework code often receives objects created by external code, ORM frameworks, serialization libraries, or IoC containers you don't control.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
// Scenario: You're building a validation framework
// Users apply your decorators to their model classes
 
@Validated
class UserRegistration {
    @Required()
    @Email()
    email: string;
 
    @Required()
    @MinLength(8)
    password: string;
}
 
// Your framework needs to:
// 1. Intercept when this class is validated
// 2. Run the validation rules
// 3. Access shared infrastructure (logger, localization, custom validators)
 
// THE PROBLEM: You don't control how UserRegistration is created
// It might be created by:
// - Direct instantiation: new UserRegistration()
// - JSON deserialization: JSON.parse(body, reviver)
// - ORM hydration: orm.findOne(UserRegistration, id)
// - Form binding: formBinder.bind(formData, UserRegistration)
 
// YOU CANNOT inject dependencies into UserRegistration
// The user creates it. You just receive it.
 
// So your framework code must resolve shared services somehow:
 
class RequiredValidator implements IValidator {
    validate(value: unknown, context: ValidationContext): ValidationResult {
        // How do we get shared services here?
        // WE DON'T CONTROL INSTANTIATION of decorators or validators
        
        // Option 1: Service Locator (works, has known costs)
        const locator = ServiceLocator.getInstance();
        const i18n = locator.resolve<II18n>(ServiceTokens.I18n);
        const logger = locator.resolve<ILogger>(ServiceTokens.Logger);
        
        if (value === undefined || value === null) {
            logger.debug(`Required validation failed for ${context.propertyName}`);
            return {
                valid: false,
                message: i18n.translate('validation.required', {
                    field: context.propertyName
                })
            };
        }
        return { valid: true };
    }
}
 
// Option 2: Inject via context object (hybrid approach)
class RequiredValidator implements IValidator {
    validate(
        value: unknown, 
        context: ValidationContext // context carries services
    ): ValidationResult {
        const { i18n, logger } = context.services; // Passed through context
        // ...
    }
}
 
// The key distinction:
// - YOUR library code may need Service Locator internally
// - Your USERS' code should ideally use DI
// - You provide the infrastructure that makes DI possible for users

Framework examples where Service Locator is commonly used:

Legitimate Framework Use Cases

•Validation frameworks — Validators triggered by decorators/attributes need access to shared services (localization, custom validator registry)
•ORM entity callbacks — beforeSave/afterLoad hooks on entities created by the ORM, not by application code
•Serialization processors — Custom converters invoked during JSON/XML serialization
•Logging frameworks — Logger factories that need configuration without constructor injection
•Plugin systems — Plugins that may need framework services but are instantiated by plugin loaders
•Aspect-oriented code — Interceptors and cross-cutting concerns applied via reflection/decoration

Contain the Locator Usage

When Service Locator is necessary in framework code, contain it within the framework boundary. The framework uses Service Locator internally, but exposes DI-friendly interfaces to application code. Application developers shouldn't need to interact with the locator directly.

Legacy System Integration

Real-world software engineering often involves working with legacy systems that weren't designed for modern dependency injection. Sometimes Service Locator is the pragmatic bridge between old and new.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
// Scenario: Integrating modern services into a legacy application
// The legacy app uses static methods and singletons everywhere
 
// Legacy code you CANNOT easily change (10 years old, 500k lines)
class LegacyReportEngine {
    static generateReport(reportId: string): Report {
        // This is called from 200 places across the codebase
        // Changing it to use DI would require massive refactoring
        
        const data = LegacyDatabase.query(reportId);
        const template = LegacyFileSystem.readTemplate(reportId);
        return LegacyRenderer.render(template, data);
    }
}
 
// New requirement: Add audit logging to report generation
// But LegacyReportEngine is static - can't inject dependencies
 
// OPTION 1: Refactor the entire legacy system (expensive, risky)
// - Change LegacyReportEngine to use DI
// - Update all 200 call sites
// - Update tests
// - Risk breaking production
 
// OPTION 2: Use Service Locator as a bridge (pragmatic, contained)
class LegacyReportEngine {
    static generateReport(reportId: string): Report {
        // New: Access modern audit service via locator
        const locator = ModernServiceLocator.getInstance();
        const auditService = locator.resolve<IAuditService>(ServiceTokens.Audit);
        
        auditService.log('report_generation_started', { reportId });
        
        try {
            const data = LegacyDatabase.query(reportId);
            const template = LegacyFileSystem.readTemplate(reportId);
            const report = LegacyRenderer.render(template, data);
            
            auditService.log('report_generation_completed', { reportId });
            return report;
        } catch (error) {
            auditService.log('report_generation_failed', { reportId, error });
            throw error;
        }
    }
}
 
// The locator bridges the gap:
// - Legacy code uses static methods (can't change)
// - Modern services use DI (well-designed)
// - Locator connects them with minimal legacy code changes
 
// This is a TRANSITIONAL pattern:
// - Use it to add new capabilities to legacy systems
// - Gradually refactor legacy code to use DI
// - Eventually eliminate the locator bridge

Key principle: Use Service Locator as a transitional bridge, not a permanent solution.

When integrating with legacy systems, Service Locator lets you add new capabilities without massive refactoring. The goal is to:

Introduce the locator minimally in legacy code
Keep new code using DI
Gradually refactor legacy code toward DI
Eventually remove the locator bridge

This is pragmatic engineering: accepting temporary imperfection to make progress.

Beware Permanent Bridges

The danger is that 'transitional' becomes permanent. Without active effort, the Service Locator bridge can become entrenched as new legacy code. Set explicit goals for reducing locator usage and track progress. Otherwise, you're just creating new legacy code.

Cross-Cutting Concerns

Cross-cutting concerns are aspects that apply across many components: logging, metrics, tracing, authorization, and similar infrastructure. These often have characteristics that make Service Locator more acceptable:

They're truly pervasive (used almost everywhere)
They're typically singleton services
They rarely change implementations at runtime
The dependency is obvious and well-known

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
// Logging is arguably the most pervasive cross-cutting concern
// Virtually every class in a system might need logging
 
// PURE DI approach: Every class takes ILogger
class UserService {
    constructor(
        private userRepo: IUserRepository,
        private validator: IValidator,
        private eventPublisher: IEventPublisher,
        private logger: ILogger  // Yet another constructor parameter
    ) {}
}
 
class OrderService {
    constructor(
        private orderRepo: IOrderRepository,
        private inventoryService: IInventoryService,
        private paymentService: IPaymentService,
        private shippingService: IShippingService,
        private logger: ILogger  // And here
    ) {}
}
 
class PaymentProcessor {
    constructor(
        private gateway: IPaymentGateway,
        private fraudDetector: IFraudDetector,
        private logger: ILogger  // And here
    ) {}
}
 
// Every single class in the system takes ILogger
// The composition root becomes verbose
// The pattern feels mechanical rather than informative
 
// ---
 
// ALTERNATIVE: Static logger factory (bounded Service Locator)
class Logger {
    private static factory: ILoggerFactory;
    
    static configure(factory: ILoggerFactory): void {
        Logger.factory = factory;
    }
    
    static getLogger(category: string): ILogger {
        if (!Logger.factory) {
            throw new Error('Logger not configured. Call Logger.configure() at startup.');
        }
        return Logger.factory.create(category);
    }
}
 
// Usage in classes:
class UserService {
    private readonly logger = Logger.getLogger('UserService');
    
    constructor(
        private userRepo: IUserRepository,
        private validator: IValidator,
        private eventPublisher: IEventPublisher
        // No logger parameter - constructor stays focused on domain
    ) {}
}
 
// Configuration at startup:
Logger.configure(new StructuredLoggerFactory(config.logLevel));
 
// This is TECHNICALLY a Service Locator pattern
// But with specific characteristics that mitigate the problems:
// 1. Single, well-known service (logging)
// 2. Configured once at startup, never changes
// 3. Obvious and expected by all developers
// 4. Still testable: Logger.configure(mockFactory) in tests

When cross-cutting concerns via Service Locator is acceptable:

Criteria for Acceptable Locator Usage

•Universal usage — The service is used in nearly every component (logging, metrics, tracing)
•Stable implementation — The implementation almost never changes after initial configuration
•Well-known convention — All developers know this service exists and how to access it
•Singleton nature — There's genuinely only one instance needed (the 'current logger')
•Configuration at startup — Set once during bootstrap, not modified during execution
•Easy test override — Tests can easily substitute with test doubles via the same static method

It's Still a Tradeoff

Using Service Locator for logging still has costs: hidden dependency, global state, etc. But when literally every class uses logging, these costs may be acceptable compared to constructor pollution. The key is consciously choosing the tradeoff, not accidentally falling into it.

Composition Root Internal Usage

There's an interesting nuance: using Service Locator patterns inside the composition root is quite different from using them throughout the application. The composition root is already special code that knows about all dependencies.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
// The composition root is where object graphs are constructed
// Using a registry/container here is fundamentally different
// from using it in application code
 
// Pure manual composition (no container):
function createApplicationRoot(): Application {
    const config = new EnvironmentConfig();
    const logger = new ConsoleLogger(config.logLevel);
    const database = new PostgresConnection(config.dbUrl);
    
    const userRepo = new PostgresUserRepository(database);
    const orderRepo = new PostgresOrderRepository(database);
    
    const emailService = new SmtpEmailService(config.smtpSettings);
    const userService = new UserService(userRepo, emailService, logger);
    const orderService = new OrderService(orderRepo, userService, logger);
    
    return new Application([
        new UserController(userService),
        new OrderController(orderService)
    ]);
}
 
// Container-based composition (using locator internally):
function createApplicationRoot(): Application {
    const container = new Container();
    
    // Register all services  
    container.register(ServiceTokens.Config, () => new EnvironmentConfig());
    container.register(ServiceTokens.Logger, (c) => 
        new ConsoleLogger(c.resolve(ServiceTokens.Config).logLevel)
    );
    container.register(ServiceTokens.Database, (c) => 
        new PostgresConnection(c.resolve(ServiceTokens.Config).dbUrl)
    );
    container.register(ServiceTokens.UserRepo, (c) =>
        new PostgresUserRepository(c.resolve(ServiceTokens.Database))
    );
    // ... etc
    
    // Resolve the root objects
    return new Application([
        container.resolve(ServiceTokens.UserController),
        container.resolve(ServiceTokens.OrderController)
    ]);
}
 
// KEY INSIGHT: 
// The container is ONLY used within the composition root
// UserService, OrderService, etc. use CONSTRUCTOR INJECTION
// They don't know about the container
 
class UserService {
    // Still uses DI - no container reference
    constructor(
        private readonly userRepo: IUserRepository,
        private readonly emailService: IEmailService,
        private readonly logger: ILogger
    ) {}
}
 
// The container resolves: UserService needs IUserRepository, IEmailService, ILogger
// It provides them via constructor injection
// UserService is completely container-agnostic

Why this is acceptable:

Using a container/locator within the composition root:

Doesn't hide dependencies — Application classes still declare explicit constructor dependencies
Keeps resolution centralized — Only the composition root interacts with the container
Improves composition ergonomics — Automatic dependency resolution is convenient
Maintains testability — Application classes are still testable via direct instantiation

The container becomes an implementation detail of the composition root, not a pervasive pattern throughout the application.

IoC Containers Are Specialized Locators

Modern IoC containers (Inversify, tsyringe, Spring, etc.) are essentially sophisticated Service Locators that integrate with constructor injection. They handle resolution internally but deliver dependencies via injection. This gives you container convenience without spreading locator calls throughout your code.

Performance-Critical Paths

In rare cases, the overhead of deep dependency injection can matter. For extremely performance-critical paths, a contained Service Locator might reduce allocation overhead or initialization costs.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
// Scenario: High-frequency trading system
// Processing 1 million messages per second
// Every microsecond matters
 
// Deep DI can create overhead:
// - Object allocation for each request
// - Constructor injection chains
// - Scope resolution per request
 
class MessageProcessor {
    constructor(
        private validator: IValidator,
        private enricher: IEnricher,
        private router: IRouter,
        private serializer: ISerializer,
        private logger: ILogger
        // Each request creates this chain
    ) {}
}
 
// For 1M requests/sec, even small allocation overhead matters
 
// Alternative: Cached Service Locator access
class OptimizedMessageProcessor {
    // Resolve once, cache for reuse
    private static validator: IValidator;
    private static enricher: IEnricher;
    private static router: IRouter;
    private static serializer: ISerializer;
    
    static initialize(): void {
        const locator = ServiceLocator.getInstance();
        // Cache references - no allocation per request
        this.validator = locator.resolve(ServiceTokens.Validator);
        this.enricher = locator.resolve(ServiceTokens.Enricher);
        this.router = locator.resolve(ServiceTokens.Router);
        this.serializer = locator.resolve(ServiceTokens.Serializer);
    }
    
    static process(message: Message): void {
        // Hot path: no allocation, no resolution
        // Just direct method calls on cached singletons
        const validated = this.validator.validate(message);
        const enriched = this.enricher.enrich(validated);
        const route = this.router.route(enriched);
        this.serializer.serialize(route);
    }
}
 
// CRITICAL CAVEAT: This is almost NEVER necessary
// Modern runtimes are extremely efficient at:
// - Object allocation and GC
// - Constructor invocation
// - Escape analysis and stack allocation
 
// ONLY use this pattern when:
// 1. Profiling proves DI overhead is significant
// 2. The path is genuinely ultra-hot (millions/sec)
// 3. You've exhausted other optimization avenues
// 4. The tradeoffs (testability, etc.) are acceptable

Premature Optimization Warning

Using Service Locator for 'performance' without profiling data is premature optimization. Modern systems can construct millions of objects per second. Unless profiling proves DI is your bottleneck (extremely rare), don't sacrifice design quality for imagined performance gains.

Scripting and Rapid Prototyping

In scripting environments or rapid prototypes where code longevity isn't a concern, the overhead of proper DI might not be worth it. This is code that will be thrown away or completely rewritten.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
// Scenario: Quick prototype to validate a concept
// Expected lifetime: 2 weeks
// Will be rewritten completely if concept proves viable
 
// Setting up proper DI infrastructure:
// - Define interfaces
// - Configure container
// - Wire up composition root
// - Set up test infrastructure
// Estimated: 4 hours
 
// Quick and dirty with global services:
// - Define services as singletons
// - Access globally
// Estimated: 30 minutes
 
// For a 2-week throwaway prototype, the 30-minute approach wins
 
// prototype.ts
const db = new QuickSqliteDb('./prototype.db');
const api = new QuickHttpClient('https://api.example.com');
const cache = new MemoryCache();
 
class PrototypeService {
    async processData() {
        // Just use globals - this is throwaway code
        const data = await api.get('/data');
        cache.set('data', data);
        await db.insert('data', data);
    }
}
 
// Run the prototype
const service = new PrototypeService();
service.processData().then(() => console.log('Done'));
 
// CRITICAL: This is ONLY acceptable when:
// 1. The code has a very short expected lifespan
// 2. It will NOT evolve into production code
// 3. You're validating concepts, not building features
// 4. You have discipline to throw it away

Prototypes Become Production

The biggest risk is that 'prototype' becomes 'production' without rewrites. If there's ANY chance the code will survive, invest in proper DI from the start. The prototype excuse has launched countless legacy codebases.

Guidelines for prototype code:

Define an end date — The prototype expires on a specific date
Don't integrate — Keep prototype code separate from production
Be honest — If you're calling it a prototype but hoping it survives, it's not a prototype
Prefer DI anyway — Modern DI libraries take minutes to set up; the overhead is smaller than you think

Mitigating Service Locator When Required

When you must use Service Locator—whether for framework code, legacy integration, or other valid reasons—you can mitigate its problems with careful discipline.

Mitigation Strategies

•Contain usage — Limit Service Locator to specific layers or modules. Most of your code should still use DI.
•Resolve in constructors — If using locator, resolve dependencies in constructors, not in methods. This at least makes resolution predictable.
•Document prominently — Make hidden dependencies visible through documentation and comments where they can't be in the signature.
•Fail fast — Resolve all dependencies during object construction, not lazily during method calls. Fail early if something is missing.
•Type-safe resolution — Use typed tokens/identifiers, not strings. Get compile-time safety for the resolution itself.
•Test thoroughly — Write integration tests that verify all required services are registered for all code paths.
•Monitor for growth — Track Service Locator usage. If it's spreading beyond intended boundaries, address it.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
// If you MUST use Service Locator, use it disciplined:
 
class PluginSystem {
    // Document the hidden dependency prominently
    /**
     * DEPENDENCIES (resolved via ServiceLocator):
     * - ILogger: Required for plugin lifecycle logging
     * - IPluginRegistry: Required for plugin registration
     * - IEventBus: Required for plugin communication
     * 
     * These services must be registered before PluginSystem is used.
     */
    
    private readonly logger: ILogger;
    private readonly registry: IPluginRegistry;
    private readonly eventBus: IEventBus;
    
    constructor() {
        // RESOLVE EVERYTHING IN CONSTRUCTOR
        // Fail fast if anything is missing
        const locator = ServiceLocator.getInstance();
        
        try {
            this.logger = locator.resolve(ServiceTokens.Logger);
            this.registry = locator.resolve(ServiceTokens.PluginRegistry);
            this.eventBus = locator.resolve(ServiceTokens.EventBus);
        } catch (error) {
            // Clear error message for missing services
            throw new Error(
                `PluginSystem requires Logger, PluginRegistry, and EventBus \
to be registered. See class documentation. Missing: ${error.message}`
            );
        }
    }
    
    // Methods use already-resolved dependencies
    // No additional resolution in methods
    loadPlugin(path: string): Plugin {
        this.logger.info(`Loading plugin from ${path}`);
        const plugin = this.registry.loadFromPath(path);
        this.eventBus.publish('plugin.loaded', plugin);
        return plugin;
    }
}
 
// Test helper to verify all required services
function verifyPluginSystemRequirements(): void {
    const locator = ServiceLocator.getInstance();
    const required = [
        ServiceTokens.Logger,
        ServiceTokens.PluginRegistry, 
        ServiceTokens.EventBus
    ];
    
    for (const token of required) {
        if (!locator.has(token)) {
            throw new Error(`Missing required service: ${token.toString()}`);
        }
    }
}

Decision Framework: DI vs Service Locator

Use this decision framework when facing a dependency management choice. The default should be Dependency Injection; Service Locator requires justification.

                    START
                      │
                      ▼
        ┌─────────────────────────────────┐
        │  Do you control instantiation?  │
        └─────────────────────────────────┘
              │                    │
             YES                  NO
              │                    │
              ▼                    ▼
        ┌──────────┐    ┌─────────────────────────┐
        │ Use DI   │    │ Framework/plugin code?  │
        └──────────┘    └─────────────────────────┘
                              │            │
                             YES          NO
                              │            │
                              ▼            ▼
                   ┌──────────────────────────────┐
                   │ Can you use IoC container    │
                   │ that injects into classes?   │
                   └──────────────────────────────┘
                         │                │
                        YES              NO
                         │                │
                         ▼                ▼
                   ┌──────────┐  ┌─────────────────────┐
                   │  Use DI  │  │ Service Locator     │
                   │  via     │  │ acceptable with     │
                   │container │  │ mitigations         │
                   └──────────┘  └─────────────────────┘

Quick Reference: When to Use What
Scenario	Recommendation	Rationale
New application code	Dependency Injection	Full benefits of explicit dependencies
Framework without instantiation control	Service Locator (contained)	Cannot inject into external objects
Legacy code integration	Service Locator (transitional)	Pragmatic bridge with refactoring plan
Universal cross-cutting (logging)	Either (conscious choice)	DI is cleaner but may be verbose
Composition root internals	IoC Container	Container is a disciplined locator for composition
Performance-critical (profiled)	Evaluate case by case	Only after proving DI is the bottleneck
Throwaway prototype	Either (short lifespan)	Minimize investment in throwaway code

Default to DI, Justify Exceptions

The key insight is treating DI as the default and Service Locator as a justified exception. When you use Service Locator, you should be able to articulate WHY: what specific constraint makes DI impractical, and what mitigations you're applying to limit the damage.

Summary: When Service Locator Is Acceptable

Experienced engineers don't follow rules blindly—they understand tradeoffs and make contextual decisions. While Service Locator is generally an anti-pattern, there are legitimate scenarios where it's acceptable or even preferable.

Key Takeaways

•Framework code — When you cannot control instantiation of objects you need to work with, Service Locator may be necessary.
•Legacy integration — Bridging old and new systems pragmatically, with explicit plans to refactor toward DI.
•Cross-cutting concerns — Truly universal services like logging may justify the tradeoff, especially with static factories.
•Composition root internals — IoC containers are sophisticated locators that power DI; using them in the composition root is fine.
•Always justify and mitigate — When using Service Locator, articulate the constraint and apply mitigation strategies.
•Default to DI — Dependency Injection should be the default; Service Locator requires justification.
•Contain the damage — Even when Service Locator is justified, keep it contained to specific boundaries.

Module Complete:

You now have a comprehensive understanding of Service Locator vs Dependency Injection. You understand Service Locator's mechanics and historical role, why it became an anti-pattern, the specific problem of hidden dependencies, and when it might still be appropriate. This nuanced understanding will serve you well in making architectural decisions throughout your career.

Module Complete

You've completed the Service Locator vs Dependency Injection module. You can now recognize Service Locator patterns, understand their tradeoffs, identify when they're problematic and when they're acceptable, and make informed decisions about dependency management strategies. This nuanced judgment distinguishes senior engineers from those who follow rules without understanding.