Inversion Of Control Containers - Learning Module

Loading content...

0/246

Popular Frameworks Overview

The IoC Container Landscape

Every major programming ecosystem has developed IoC container technologies, each reflecting the language's idioms, community priorities, and historical evolution. Some containers are built into frameworks; others are standalone libraries. Some prioritize convention over configuration; others offer maximum flexibility at the cost of complexity.

Understanding the landscape helps you choose the right tool for your context and learn from the design philosophies that emerged from different communities. Whether you're working in Java's Spring ecosystem, .NET's dependency injection system, JavaScript's module-based approaches, or Python's emerging patterns, the core concepts transfer—only the syntax and conventions differ.

This page surveys the major IoC container frameworks, their distinguishing features, and practical guidance for selection.

What You Will Learn

By the end of this page, you will understand the major IoC container frameworks across Java, .NET, JavaScript/TypeScript, and Python ecosystems. You'll learn their design philosophies, key features, strengths and weaknesses, and how to choose the right container for your specific needs.

Java Ecosystem Containers

Java pioneered enterprise dependency injection. The 2004 Spring Framework revolutionized Java development by introducing a comprehensive IoC container, and the ecosystem has evolved dramatically since then.

Spring Framework is the most comprehensive and widely-used IoC container in the Java ecosystem. Born from Rod Johnson's critique of J2EE complexity, Spring became the de facto standard for enterprise Java development.

Core Philosophy:

Convention over configuration (especially Spring Boot)
Comprehensive ecosystem (web, data, security, cloud)
Backward compatibility as a first-class concern
Community-driven evolution

Key Features:

•Multiple configuration styles — XML (legacy), annotations, Java Config (modern)
•Powerful component scanning — Automatic discovery of @Component, @Service, @Repository
•Comprehensive AOP — Full aspect-oriented programming with @Aspect
•Bean lifecycle hooks — @PostConstruct, @PreDestroy, InitializingBean, DisposableBean
•Extensive scopes — Singleton, prototype, request, session, custom scopes
•Spring Boot auto-configuration — Opinionated defaults, minimal boilerplate

Java
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
// SPRING FRAMEWORK EXAMPLE
 
// Service definition with @Service stereotype
@Service
public class UserService {
    private final UserRepository repository;
    private final PasswordEncoder encoder;
    
    // Constructor injection (preferred)
    @Autowired
    public UserService(UserRepository repository, PasswordEncoder encoder) {
        this.repository = repository;
        this.encoder = encoder;
    }
    
    public User createUser(String email, String password) {
        String encoded = encoder.encode(password);
        return repository.save(new User(email, encoded));
    }
}
 
// Configuration class for explicit beans
@Configuration
public class SecurityConfig {
    
    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }
    
    @Bean
    @ConditionalOnProperty(name = "auth.enabled", havingValue = "true")
    public AuthenticationManager authManager(UserService userService) {
        return new UserAuthenticationManager(userService);
    }
}
 
// Main application with Spring Boot
@SpringBootApplication
@ComponentScan(basePackages = "com.example")
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

Best For: Enterprise applications, microservices, teams needing comprehensive ecosystem support.

Limitations: Can feel heavyweight for simple applications; startup time can be slow without GraalVM native compilation; learning curve is steep for the full ecosystem.

.NET Ecosystem Containers

.NET has evolved from relying on third-party containers to having built-in dependency injection in ASP.NET Core. The ecosystem offers a range of options from minimal built-in DI to feature-rich third-party alternatives.

Microsoft.Extensions.DependencyInjection is the built-in DI container for .NET Core and modern .NET. It's intentionally minimal—covering the most common scenarios while remaining extensible.

Core Philosophy:

Built-in, no external dependencies
Minimal API surface for core scenarios
Extensible through IServiceProvider abstraction
First-class ASP.NET Core integration

Key Features:

•Three lifecycles — Singleton, Scoped, Transient (covers 95% of needs)
•IServiceCollection — Builder pattern for registration
•Constructor injection — Automatic parameter resolution
•Factory registration — Func-based registration for complex cases
•Open generics — Register IRepository<> once, resolve IRepository<User>
•Framework integration — ASP.NET Core, Worker Services, EF Core, etc.

C#
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
// MICROSOFT.EXTENSIONS.DEPENDENCYINJECTION EXAMPLE
 
// Program.cs - Modern .NET 6+ style
var builder = WebApplication.CreateBuilder(args);
 
// Register services
builder.Services.AddSingleton<ILogger, ConsoleLogger>();
builder.Services.AddScoped<IUserRepository, PostgresUserRepository>();
builder.Services.AddTransient<IValidator, InputValidator>();
 
// Open generic registration
builder.Services.AddScoped(typeof(IRepository<>), typeof(EfRepository<>));
 
// Factory registration for complex construction
builder.Services.AddSingleton<IPaymentGateway>(sp =>
{
    var config = sp.GetRequiredService<IConfiguration>();
    var logger = sp.GetRequiredService<ILogger>();
    return new StripeGateway(config["Stripe:ApiKey"], logger);
});
 
// Conditional registration based on configuration
if (builder.Environment.IsDevelopment())
{
    builder.Services.AddSingleton<IEmailService, FakeEmailService>();
}
else
{
    builder.Services.AddSingleton<IEmailService, SendGridService>();
}
 
var app = builder.Build();
 
// Services resolved during request handling via DI
app.MapGet("/users/{id}", async (
    int id,
    IUserRepository repository,  // Injected by framework
    ILogger logger               // Injected by framework
) =>
{
    logger.Log($"Getting user {id}");
    var user = await repository.FindByIdAsync(id);
    return user is not null ? Results.Ok(user) : Results.NotFound();
});
 
app.Run();
 
// Service implementation - dependencies via constructor
public class UserService : IUserService
{
    private readonly IUserRepository _repository;
    private readonly ILogger _logger;
    
    public UserService(IUserRepository repository, ILogger logger)
    {
        _repository = repository;
        _logger = logger;
    }
    
    public async Task<User> CreateUserAsync(string email)
    {
        _logger.Log($"Creating user: {email}");
        return await _repository.CreateAsync(new User(email));
    }
}

Best For: Most .NET applications, ASP.NET Core projects, teams wanting zero external dependencies.

Limitations: No decorators, no interception, no keyed services (prior to .NET 8), no auto-registration by convention.

JavaScript/TypeScript Ecosystem

JavaScript's module system and dynamic nature mean DI is often handled differently than in statically-typed languages. However, TypeScript's rise has enabled more traditional IoC container patterns. The ecosystem ranges from framework-integrated DI to standalone libraries.

NestJS is a progressive Node.js framework with built-in dependency injection inspired by Angular. It's the most popular DI-enabled framework in the Node.js ecosystem.

Core Philosophy:

Angular-inspired architecture for the backend
First-class TypeScript support
Decorator-based configuration
Modular application structure

Key Features:

•Module system — @Module decorator organizes components
•Provider scopes — DEFAULT (singleton), REQUEST, TRANSIENT
•Custom providers — useClass, useValue, useFactory, useExisting
•Injection tokens — Support for non-class dependencies
•Async providers — Factory providers can return Promises
•Request-scoped providers — New instance per HTTP request

TypeScript
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
75
76
77
78
79
80
81
// NESTJS EXAMPLE
 
// Service with @Injectable decorator
@Injectable()
export class UserService {
  constructor(
    private readonly repository: UserRepository,
    private readonly logger: LoggerService,
  ) {}
  
  async createUser(email: string): Promise<User> {
    this.logger.log(`Creating user: ${email}`);
    return this.repository.create({ email });
  }
}
 
// Module defines what's provided and exported
@Module({
  imports: [DatabaseModule, LoggerModule],
  controllers: [UserController],
  providers: [
    UserService,
    UserRepository,
    // Custom provider with factory
    {
      provide: 'CONFIG',
      useFactory: async (configService: ConfigService) => {
        return await configService.loadFromVault();
      },
      inject: [ConfigService],
    },
    // Conditional provider
    {
      provide: 'PAYMENT_GATEWAY',
      useFactory: (config: ConfigService) => {
        if (config.get('ENVIRONMENT') === 'production') {
          return new StripeGateway(config.get('STRIPE_KEY'));
        }
        return new MockPaymentGateway();
      },
      inject: [ConfigService],
    },
  ],
  exports: [UserService],
})
export class UserModule {}
 
// Controller with constructor injection
@Controller('users')
export class UserController {
  constructor(
    private readonly userService: UserService,
    @Inject('CONFIG') private readonly config: AppConfig,
  ) {}
  
  @Post()
  async create(@Body() dto: CreateUserDto): Promise<User> {
    return this.userService.createUser(dto.email);
  }
}
 
// Request-scoped provider
@Injectable({ scope: Scope.REQUEST })
export class RequestContextService {
  private requestId: string;
  
  setRequestId(id: string) {
    this.requestId = id;
  }
  
  getRequestId(): string {
    return this.requestId;
  }
}
 
// Main application bootstrap
async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  await app.listen(3000);
}
bootstrap();

Best For: Enterprise Node.js applications, teams from Angular background, microservices architecture.

Limitations: Framework lock-in; decorator dependency; not suitable for frontend or non-NestJS projects.

Python Ecosystem

Python's dynamic nature and duck typing mean DI patterns differ from statically-typed languages. Containers exist but are less prevalent; many Python projects use simpler patterns. However, type hints and FastAPI's popularity have increased interest in DI.

Dependency Injector is the most full-featured DI framework for Python. It provides a container-based approach similar to Java/C# containers.

Core Philosophy:

Explicit, container-based DI
Type-hint aware
Wiring for automatic injection
Multiple provider types

Key Features:

•Multiple providers — Factory, Singleton, Callable, Object, Configuration
•Wiring — Automatic injection based on type hints
•Overriding — Easy swapping for testing
•Configuration provider — Load config from YAML/JSON/env
•Async support — Works with async/await
•Thread safety — Safe for concurrent access

Python
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
75
76
77
78
79
80
81
82
83
84
85
86
87
88
# DEPENDENCY INJECTOR EXAMPLE
 
from dependency_injector import containers, providers
from dependency_injector.wiring import Provide, inject
 
# Service classes
class UserRepository:
    def __init__(self, db_client: DatabaseClient):
        self.db = db_client
    
    def find_by_id(self, user_id: str) -> User | None:
        return self.db.query(User).get(user_id)
 
class UserService:
    def __init__(self, repository: UserRepository, logger: Logger):
        self.repository = repository
        self.logger = logger
    
    def get_user(self, user_id: str) -> User:
        self.logger.info(f"Getting user: {user_id}")
        return self.repository.find_by_id(user_id)
 
# Container definition
class Container(containers.DeclarativeContainer):
    
    config = providers.Configuration()
    
    # Singleton logger
    logger = providers.Singleton(
        Logger,
        level=config.logging.level,
    )
    
    # Database client
    db_client = providers.Singleton(
        DatabaseClient,
        connection_string=config.database.url,
    )
    
    # Repository (factory - new instance each time)
    user_repository = providers.Factory(
        UserRepository,
        db_client=db_client,
    )
    
    # Service
    user_service = providers.Factory(
        UserService,
        repository=user_repository,
        logger=logger,
    )
 
# Wiring for automatic injection
@inject
def get_user_endpoint(
    user_id: str,
    user_service: UserService = Provide[Container.user_service],
) -> dict:
    user = user_service.get_user(user_id)
    return {"id": user.id, "email": user.email}
 
# Application setup
container = Container()
container.config.from_yaml("config.yaml")
container.wire(modules=[__name__])
 
# Testing with overrides
def test_get_user():
    mock_repo = Mock(spec=UserRepository)
    mock_repo.find_by_id.return_value = User(id="1", email="test@example.com")
    
    with container.user_repository.override(providers.Object(mock_repo)):
        result = get_user_endpoint("1")
        assert result["email"] == "test@example.com"
 
# FastAPI integration
from fastapi import FastAPI, Depends
from dependency_injector.wiring import inject, Provide
 
app = FastAPI()
 
@app.get("/users/{user_id}")
@inject
async def get_user(
    user_id: str,
    user_service: UserService = Depends(Provide[Container.user_service]),
):
    return user_service.get_user(user_id)

Best For: Complex Python applications, FastAPI projects, teams familiar with DI patterns from other languages.

Limitations: Can feel over-engineered for simple Python projects; learning curve for Python developers unfamiliar with DI.

Choosing the Right Container

Container selection depends on multiple factors: language ecosystem, framework choice, team experience, project complexity, and required features. There's rarely a universally 'best' container—only the best for your specific context.

Container Selection Decision Matrix
Scenario	Recommended Container	Rationale
Java enterprise microservices	Spring Boot	Comprehensive ecosystem, mature tooling, industry standard
Java startup needing fast boot	Google Guice + Micronaut	Faster startup, minimal overhead, GraalVM compatible
.NET Core web API (standard)	Built-in MS DI	No dependencies, framework integration, sufficient for most
.NET requiring AOP/decorators	Autofac	Full decorator support, interception, advanced features
Node.js enterprise application	NestJS	Structured framework, Angular-like DI, TypeScript first
TypeScript library/frontend	InversifyJS or TSyringe	Framework-agnostic, works anywhere TypeScript works
Python FastAPI application	FastAPI Depends	Native integration, simple, idiomatic Python
Python complex DI needs	Dependency Injector	Full container features, testing support, configuration

Key Selection Criteria

•Team Familiarity — A container the team knows beats a 'better' container nobody understands.
•Framework Integration — If your framework includes DI, use it unless you need features it lacks.
•Required Features — Do you need decorators? Interception? Open generics? List must-haves first.
•Ecosystem Compatibility — Does the container work with your database library, web framework, etc.?
•Startup Performance — For serverless or CLI apps, startup time matters. Some containers are slower.
•Learning Resources — Popular containers have better documentation, tutorials, and Stack Overflow answers.
•Long-Term Maintenance — Is the container actively maintained? What's the community size?

When in Doubt, Start Simple

Start with the simplest container that meets your needs—often the built-in option. You can always migrate to a more feature-rich container later if requirements evolve. Premature complexity is its own maintenance burden.

Container-Agnostic Best Practices

Regardless of which container you choose, certain practices ensure maintainable, testable dependency injection:

Universal Best Practices

•Depend on interfaces, not concrete classes — The core DIP principle. Makes swapping implementations trivial.
•Constructor injection by default — Dependencies are explicit, immutable, and required at construction time.
•Keep constructors focused — If a class needs many dependencies, it may have too many responsibilities (SRP violation).
•Single composition root — Configure the container in one place at application startup.
•Avoid service locator pattern — Never inject the container itself; always use constructor injection.
•Be explicit about lifecycles — Understand and document whether services are singleton, scoped, or transient.
•Test with real DI in integration tests — Unit tests mock dependencies; integration tests exercise the real container configuration.
•Validate configuration at startup — Fail fast if registrations are missing or circular.

Patterns Transfer, Syntax Differs

Once you deeply understand DI principles and container patterns, switching between frameworks becomes a syntax exercise. The concepts—registration, resolution, lifecycle, scoping—are universal. Learn once, apply everywhere.

Summary: The IoC Container Ecosystem

We've surveyed the major IoC container frameworks across the Java, .NET, JavaScript/TypeScript, and Python ecosystems. Each reflects its language's idioms and community priorities while implementing the same fundamental DI concepts.

Key Takeaways

•Java has mature options — Spring dominates enterprise; Guice offers lightweight alternative; CDI provides standards-based approach.
•.NET has built-in + extensions — Microsoft.Extensions.DI covers basics; Autofac adds decorators and interception.
•JavaScript/TypeScript is framework-driven — NestJS provides Angular-like DI; InversifyJS and TSyringe work standalone.
•Python's ecosystem is simpler — FastAPI Depends handles web cases; Dependency Injector provides full container features.
•Container selection is context-dependent — Team familiarity, required features, and framework integration guide the choice.
•Principles are universal — Registration, resolution, lifecycle, and scoping work similarly across all containers.
•Start simple, evolve as needed — Use built-in options when sufficient; migrate to feature-rich alternatives when requirements demand.

Module Complete:

You've now completed the Inversion of Control Containers module. You understand what containers are, how to configure them, how resolution works, and the major frameworks available across ecosystems. This knowledge, combined with the earlier DIP modules on abstractions and dependency injection, gives you a complete toolkit for managing dependencies in enterprise applications.

Next, we'll explore how DIP enables testability—one of its most practical benefits—in the final module of the Dependency Inversion Principle chapter.

Page Complete

You now have comprehensive knowledge of IoC container frameworks: Java (Spring, Guice, CDI), .NET (MS DI, Autofac), JavaScript/TypeScript (NestJS, InversifyJS, TSyringe), and Python (Dependency Injector, FastAPI). You understand how to select containers and the universal practices that apply regardless of framework choice.

Popular Frameworks Overview

The IoC Container Landscape

This page surveys the major IoC container frameworks, their distinguishing features, and practical guidance for selection.

What You Will Learn

Java Ecosystem Containers

Core Philosophy:

Convention over configuration (especially Spring Boot)
Comprehensive ecosystem (web, data, security, cloud)
Backward compatibility as a first-class concern
Community-driven evolution

Key Features:

•Multiple configuration styles — XML (legacy), annotations, Java Config (modern)
•Powerful component scanning — Automatic discovery of @Component, @Service, @Repository
•Comprehensive AOP — Full aspect-oriented programming with @Aspect
•Bean lifecycle hooks — @PostConstruct, @PreDestroy, InitializingBean, DisposableBean
•Extensive scopes — Singleton, prototype, request, session, custom scopes
•Spring Boot auto-configuration — Opinionated defaults, minimal boilerplate

Java
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
// SPRING FRAMEWORK EXAMPLE
 
// Service definition with @Service stereotype
@Service
public class UserService {
    private final UserRepository repository;
    private final PasswordEncoder encoder;
    
    // Constructor injection (preferred)
    @Autowired
    public UserService(UserRepository repository, PasswordEncoder encoder) {
        this.repository = repository;
        this.encoder = encoder;
    }
    
    public User createUser(String email, String password) {
        String encoded = encoder.encode(password);
        return repository.save(new User(email, encoded));
    }
}
 
// Configuration class for explicit beans
@Configuration
public class SecurityConfig {
    
    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }
    
    @Bean
    @ConditionalOnProperty(name = "auth.enabled", havingValue = "true")
    public AuthenticationManager authManager(UserService userService) {
        return new UserAuthenticationManager(userService);
    }
}
 
// Main application with Spring Boot
@SpringBootApplication
@ComponentScan(basePackages = "com.example")
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

Best For: Enterprise applications, microservices, teams needing comprehensive ecosystem support.

Limitations: Can feel heavyweight for simple applications; startup time can be slow without GraalVM native compilation; learning curve is steep for the full ecosystem.

.NET Ecosystem Containers

Microsoft.Extensions.DependencyInjection is the built-in DI container for .NET Core and modern .NET. It's intentionally minimal—covering the most common scenarios while remaining extensible.

Core Philosophy:

Built-in, no external dependencies
Minimal API surface for core scenarios
Extensible through IServiceProvider abstraction
First-class ASP.NET Core integration

Key Features:

•Three lifecycles — Singleton, Scoped, Transient (covers 95% of needs)
•IServiceCollection — Builder pattern for registration
•Constructor injection — Automatic parameter resolution
•Factory registration — Func-based registration for complex cases
•Open generics — Register IRepository<> once, resolve IRepository<User>
•Framework integration — ASP.NET Core, Worker Services, EF Core, etc.

C#
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
// MICROSOFT.EXTENSIONS.DEPENDENCYINJECTION EXAMPLE
 
// Program.cs - Modern .NET 6+ style
var builder = WebApplication.CreateBuilder(args);
 
// Register services
builder.Services.AddSingleton<ILogger, ConsoleLogger>();
builder.Services.AddScoped<IUserRepository, PostgresUserRepository>();
builder.Services.AddTransient<IValidator, InputValidator>();
 
// Open generic registration
builder.Services.AddScoped(typeof(IRepository<>), typeof(EfRepository<>));
 
// Factory registration for complex construction
builder.Services.AddSingleton<IPaymentGateway>(sp =>
{
    var config = sp.GetRequiredService<IConfiguration>();
    var logger = sp.GetRequiredService<ILogger>();
    return new StripeGateway(config["Stripe:ApiKey"], logger);
});
 
// Conditional registration based on configuration
if (builder.Environment.IsDevelopment())
{
    builder.Services.AddSingleton<IEmailService, FakeEmailService>();
}
else
{
    builder.Services.AddSingleton<IEmailService, SendGridService>();
}
 
var app = builder.Build();
 
// Services resolved during request handling via DI
app.MapGet("/users/{id}", async (
    int id,
    IUserRepository repository,  // Injected by framework
    ILogger logger               // Injected by framework
) =>
{
    logger.Log($"Getting user {id}");
    var user = await repository.FindByIdAsync(id);
    return user is not null ? Results.Ok(user) : Results.NotFound();
});
 
app.Run();
 
// Service implementation - dependencies via constructor
public class UserService : IUserService
{
    private readonly IUserRepository _repository;
    private readonly ILogger _logger;
    
    public UserService(IUserRepository repository, ILogger logger)
    {
        _repository = repository;
        _logger = logger;
    }
    
    public async Task<User> CreateUserAsync(string email)
    {
        _logger.Log($"Creating user: {email}");
        return await _repository.CreateAsync(new User(email));
    }
}

Best For: Most .NET applications, ASP.NET Core projects, teams wanting zero external dependencies.

Limitations: No decorators, no interception, no keyed services (prior to .NET 8), no auto-registration by convention.

JavaScript/TypeScript Ecosystem

NestJS is a progressive Node.js framework with built-in dependency injection inspired by Angular. It's the most popular DI-enabled framework in the Node.js ecosystem.

Core Philosophy:

Angular-inspired architecture for the backend
First-class TypeScript support
Decorator-based configuration
Modular application structure

Key Features:

•Module system — @Module decorator organizes components
•Provider scopes — DEFAULT (singleton), REQUEST, TRANSIENT
•Custom providers — useClass, useValue, useFactory, useExisting
•Injection tokens — Support for non-class dependencies
•Async providers — Factory providers can return Promises
•Request-scoped providers — New instance per HTTP request

TypeScript
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
75
76
77
78
79
80
81
// NESTJS EXAMPLE
 
// Service with @Injectable decorator
@Injectable()
export class UserService {
  constructor(
    private readonly repository: UserRepository,
    private readonly logger: LoggerService,
  ) {}
  
  async createUser(email: string): Promise<User> {
    this.logger.log(`Creating user: ${email}`);
    return this.repository.create({ email });
  }
}
 
// Module defines what's provided and exported
@Module({
  imports: [DatabaseModule, LoggerModule],
  controllers: [UserController],
  providers: [
    UserService,
    UserRepository,
    // Custom provider with factory
    {
      provide: 'CONFIG',
      useFactory: async (configService: ConfigService) => {
        return await configService.loadFromVault();
      },
      inject: [ConfigService],
    },
    // Conditional provider
    {
      provide: 'PAYMENT_GATEWAY',
      useFactory: (config: ConfigService) => {
        if (config.get('ENVIRONMENT') === 'production') {
          return new StripeGateway(config.get('STRIPE_KEY'));
        }
        return new MockPaymentGateway();
      },
      inject: [ConfigService],
    },
  ],
  exports: [UserService],
})
export class UserModule {}
 
// Controller with constructor injection
@Controller('users')
export class UserController {
  constructor(
    private readonly userService: UserService,
    @Inject('CONFIG') private readonly config: AppConfig,
  ) {}
  
  @Post()
  async create(@Body() dto: CreateUserDto): Promise<User> {
    return this.userService.createUser(dto.email);
  }
}
 
// Request-scoped provider
@Injectable({ scope: Scope.REQUEST })
export class RequestContextService {
  private requestId: string;
  
  setRequestId(id: string) {
    this.requestId = id;
  }
  
  getRequestId(): string {
    return this.requestId;
  }
}
 
// Main application bootstrap
async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  await app.listen(3000);
}
bootstrap();

Best For: Enterprise Node.js applications, teams from Angular background, microservices architecture.

Limitations: Framework lock-in; decorator dependency; not suitable for frontend or non-NestJS projects.

Python Ecosystem

Dependency Injector is the most full-featured DI framework for Python. It provides a container-based approach similar to Java/C# containers.

Core Philosophy:

Explicit, container-based DI
Type-hint aware
Wiring for automatic injection
Multiple provider types

Key Features:

•Multiple providers — Factory, Singleton, Callable, Object, Configuration
•Wiring — Automatic injection based on type hints
•Overriding — Easy swapping for testing
•Configuration provider — Load config from YAML/JSON/env
•Async support — Works with async/await
•Thread safety — Safe for concurrent access

Python
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
75
76
77
78
79
80
81
82
83
84
85
86
87
88
# DEPENDENCY INJECTOR EXAMPLE
 
from dependency_injector import containers, providers
from dependency_injector.wiring import Provide, inject
 
# Service classes
class UserRepository:
    def __init__(self, db_client: DatabaseClient):
        self.db = db_client
    
    def find_by_id(self, user_id: str) -> User | None:
        return self.db.query(User).get(user_id)
 
class UserService:
    def __init__(self, repository: UserRepository, logger: Logger):
        self.repository = repository
        self.logger = logger
    
    def get_user(self, user_id: str) -> User:
        self.logger.info(f"Getting user: {user_id}")
        return self.repository.find_by_id(user_id)
 
# Container definition
class Container(containers.DeclarativeContainer):
    
    config = providers.Configuration()
    
    # Singleton logger
    logger = providers.Singleton(
        Logger,
        level=config.logging.level,
    )
    
    # Database client
    db_client = providers.Singleton(
        DatabaseClient,
        connection_string=config.database.url,
    )
    
    # Repository (factory - new instance each time)
    user_repository = providers.Factory(
        UserRepository,
        db_client=db_client,
    )
    
    # Service
    user_service = providers.Factory(
        UserService,
        repository=user_repository,
        logger=logger,
    )
 
# Wiring for automatic injection
@inject
def get_user_endpoint(
    user_id: str,
    user_service: UserService = Provide[Container.user_service],
) -> dict:
    user = user_service.get_user(user_id)
    return {"id": user.id, "email": user.email}
 
# Application setup
container = Container()
container.config.from_yaml("config.yaml")
container.wire(modules=[__name__])
 
# Testing with overrides
def test_get_user():
    mock_repo = Mock(spec=UserRepository)
    mock_repo.find_by_id.return_value = User(id="1", email="test@example.com")
    
    with container.user_repository.override(providers.Object(mock_repo)):
        result = get_user_endpoint("1")
        assert result["email"] == "test@example.com"
 
# FastAPI integration
from fastapi import FastAPI, Depends
from dependency_injector.wiring import inject, Provide
 
app = FastAPI()
 
@app.get("/users/{user_id}")
@inject
async def get_user(
    user_id: str,
    user_service: UserService = Depends(Provide[Container.user_service]),
):
    return user_service.get_user(user_id)

Best For: Complex Python applications, FastAPI projects, teams familiar with DI patterns from other languages.

Limitations: Can feel over-engineered for simple Python projects; learning curve for Python developers unfamiliar with DI.

Choosing the Right Container

Container Selection Decision Matrix
Scenario	Recommended Container	Rationale
Java enterprise microservices	Spring Boot	Comprehensive ecosystem, mature tooling, industry standard
Java startup needing fast boot	Google Guice + Micronaut	Faster startup, minimal overhead, GraalVM compatible
.NET Core web API (standard)	Built-in MS DI	No dependencies, framework integration, sufficient for most
.NET requiring AOP/decorators	Autofac	Full decorator support, interception, advanced features
Node.js enterprise application	NestJS	Structured framework, Angular-like DI, TypeScript first
TypeScript library/frontend	InversifyJS or TSyringe	Framework-agnostic, works anywhere TypeScript works
Python FastAPI application	FastAPI Depends	Native integration, simple, idiomatic Python
Python complex DI needs	Dependency Injector	Full container features, testing support, configuration

Key Selection Criteria

•Team Familiarity — A container the team knows beats a 'better' container nobody understands.
•Framework Integration — If your framework includes DI, use it unless you need features it lacks.
•Required Features — Do you need decorators? Interception? Open generics? List must-haves first.
•Ecosystem Compatibility — Does the container work with your database library, web framework, etc.?
•Startup Performance — For serverless or CLI apps, startup time matters. Some containers are slower.
•Learning Resources — Popular containers have better documentation, tutorials, and Stack Overflow answers.
•Long-Term Maintenance — Is the container actively maintained? What's the community size?

When in Doubt, Start Simple

Container-Agnostic Best Practices

Regardless of which container you choose, certain practices ensure maintainable, testable dependency injection:

Universal Best Practices

•Depend on interfaces, not concrete classes — The core DIP principle. Makes swapping implementations trivial.
•Constructor injection by default — Dependencies are explicit, immutable, and required at construction time.
•Keep constructors focused — If a class needs many dependencies, it may have too many responsibilities (SRP violation).
•Single composition root — Configure the container in one place at application startup.
•Avoid service locator pattern — Never inject the container itself; always use constructor injection.
•Be explicit about lifecycles — Understand and document whether services are singleton, scoped, or transient.
•Test with real DI in integration tests — Unit tests mock dependencies; integration tests exercise the real container configuration.
•Validate configuration at startup — Fail fast if registrations are missing or circular.

Patterns Transfer, Syntax Differs

Summary: The IoC Container Ecosystem

Key Takeaways

•Java has mature options — Spring dominates enterprise; Guice offers lightweight alternative; CDI provides standards-based approach.
•.NET has built-in + extensions — Microsoft.Extensions.DI covers basics; Autofac adds decorators and interception.
•JavaScript/TypeScript is framework-driven — NestJS provides Angular-like DI; InversifyJS and TSyringe work standalone.
•Python's ecosystem is simpler — FastAPI Depends handles web cases; Dependency Injector provides full container features.
•Container selection is context-dependent — Team familiarity, required features, and framework integration guide the choice.
•Principles are universal — Registration, resolution, lifecycle, and scoping work similarly across all containers.
•Start simple, evolve as needed — Use built-in options when sufficient; migrate to feature-rich alternatives when requirements demand.

Module Complete:

Next, we'll explore how DIP enables testability—one of its most practical benefits—in the final module of the Dependency Inversion Principle chapter.

Page Complete