System Design (LLD)IoC Container Deep Dive

IoC Container Deep Dive

LevelIntermediate

Duration60 mins

TopicIoC Container Deep Dive

2 / 4

XML vs Code vs Attribute Configuration

The Three Configuration Paradigms

IoC container configuration has evolved through distinct paradigms, each reflecting the software development philosophy of its era:

XML Configuration — The original approach, born from Java's enterprise traditions and .NET's early frameworks
Code-Based Configuration — The modern dominant approach, prioritizing type safety and tooling
Attribute-Based Configuration — A declarative approach that embeds configuration in the classes themselves

Understanding these paradigms isn't merely historical curiosity. Many production systems still use XML configuration, and attribute-based approaches remain popular for specific scenarios. A Principal Engineer must navigate all three fluently.

What You Will Learn

This page provides deep analysis of each configuration paradigm—their philosophical underpinnings, practical implementations, advantages, disadvantages, and the specific scenarios where each excels. You'll emerge equipped to evaluate existing codebases, migrate between approaches, and choose appropriately for new systems.

XML Configuration: The Declarative Pioneer

The Philosophy:

XML configuration emerged from a fundamental premise: configuration should be separate from code. In the early 2000s, this separation was seen as essential for enterprise applications where:

Operations teams deployed applications without access to source code
Configuration needed to change without recompilation
Multiple environments (dev, staging, production) required different object wiring
External parties customized behavior through configuration files

XML provided a structured, validated, tool-supported format for expressing dependency graphs externally.

application-context.xml
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
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans.xsd">
 
    <!-- Infrastructure Layer -->
    
    <!-- Logger configuration with environment-based selection -->
    <bean id="logger" class="com.example.logging.ConsoleLogger" 
          scope="singleton">
        <constructor-arg name="prefix" value="[APP]"/>
        <constructor-arg name="level" value="${logging.level:INFO}"/>
    </bean>
    
    <!-- Database with connection pooling -->
    <bean id="dataSource" class="com.zaxxer.hikari.HikariDataSource"
          destroy-method="close" scope="singleton">
        <property name="jdbcUrl" value="${database.url}"/>
        <property name="username" value="${database.username}"/>
        <property name="password" value="${database.password}"/>
        <property name="maximumPoolSize" value="10"/>
        <property name="minimumIdle" value="2"/>
    </bean>
    
    <bean id="database" class="com.example.persistence.PostgresDatabase"
          scope="singleton">
        <constructor-arg ref="dataSource"/>
        <constructor-arg ref="logger"/>
    </bean>
    
    <!-- Caching with Redis -->
    <bean id="redisConnectionFactory" 
          class="org.springframework.data.redis.connection.jedis.JedisConnectionFactory"
          scope="singleton">
        <property name="hostName" value="${redis.host:localhost}"/>
        <property name="port" value="${redis.port:6379}"/>
    </bean>
    
    <bean id="cache" class="com.example.caching.RedisCache"
          scope="singleton">
        <constructor-arg ref="redisConnectionFactory"/>
        <constructor-arg name="defaultTtl" value="300"/>
    </bean>
    
    <!-- Repository Layer -->
    
    <bean id="userRepository" class="com.example.repository.UserRepositoryImpl"
          scope="prototype">
        <constructor-arg ref="database"/>
        <constructor-arg ref="logger"/>
    </bean>
    
    <!-- Add caching decorator -->
    <bean id="cachedUserRepository" 
          class="com.example.repository.CachingUserRepositoryDecorator"
          scope="prototype">
        <constructor-arg ref="userRepository"/>
        <constructor-arg ref="cache"/>
        <property name="ttlSeconds" value="600"/>
    </bean>
    
    <bean id="orderRepository" class="com.example.repository.OrderRepositoryImpl"
          scope="prototype">
        <constructor-arg ref="database"/>
        <constructor-arg ref="logger"/>
    </bean>
    
    <!-- Service Layer -->
    
    <bean id="passwordHasher" 
          class="com.example.security.BcryptPasswordHasher"
          scope="singleton">
        <constructor-arg name="workFactor" value="12"/>
    </bean>
    
    <bean id="tokenService" 
          class="com.example.security.JwtTokenService"
          scope="singleton">
        <constructor-arg name="secretKey" value="${jwt.secret}"/>
        <constructor-arg name="expirationMinutes" value="${jwt.expiration:60}"/>
    </bean>
    
    <bean id="userService" class="com.example.service.UserServiceImpl"
          scope="request">
        <constructor-arg ref="cachedUserRepository"/>
        <constructor-arg ref="passwordHasher"/>
        <constructor-arg ref="tokenService"/>
        <constructor-arg ref="logger"/>
    </bean>
    
    <bean id="orderService" class="com.example.service.OrderServiceImpl"
          scope="request">
        <constructor-arg ref="orderRepository"/>
        <constructor-arg ref="userService"/>
        <constructor-arg ref="logger"/>
    </bean>
    
    <!-- Payment processing with factory method -->
    <bean id="paymentGatewayFactory" 
          class="com.example.payment.PaymentGatewayFactory"
          scope="singleton"/>
    
    <bean id="paymentGateway" 
          factory-bean="paymentGatewayFactory"
          factory-method="createGateway"
          scope="singleton">
        <constructor-arg value="${payment.provider:stripe}"/>
        <constructor-arg value="${payment.api.key}"/>
    </bean>
    
    <!-- Notification channels -->
    <bean id="emailSender" class="com.example.notification.SendGridEmailSender"
          scope="singleton">
        <property name="apiKey" value="${sendgrid.api.key}"/>
        <property name="fromAddress" value="${notification.email.from}"/>
    </bean>
    
    <bean id="smsSender" class="com.example.notification.TwilioSmsSender"
          scope="singleton">
        <property name="accountSid" value="${twilio.account.sid}"/>
        <property name="authToken" value="${twilio.auth.token}"/>
        <property name="fromNumber" value="${twilio.from.number}"/>
    </bean>
    
    <!-- Import modular configurations -->
    <import resource="security-context.xml"/>
    <import resource="messaging-context.xml"/>
    
</beans>

XML Configuration Advantages

•Runtime flexibility — Change implementations without recompilation by editing XML files
•Environment separation — Deploy same binary with different configuration per environment
•Schema validation — XML schemas catch configuration errors before runtime
•Non-developer access — Operations teams can modify behavior without code access
•Tooling support — Many IDEs provide XML editing with auto-completion for known schemas
•Modular imports — Split configuration across multiple files and compose

XML Configuration Disadvantages

•No compile-time type safety — Typos in class names become runtime errors
•Verbose and repetitive — Simple registrations require significant boilerplate
•Refactoring blind spots — Rename a class and XML references silently break
•Limited conditional logic — Complex registration decisions are awkward or impossible
•Debugging difficulty — Cannot step through configuration; errors often opaque
•Testing challenges — XML configuration is not easily unit testable

The String Typing Problem

XML configuration is fundamentally stringly typed—type names are strings that the compiler never sees. This means: (1) no auto-completion for class names, (2) no compile-time verification of constructor parameters, (3) no refactoring support, and (4) runtime failures instead of compile-time failures. These costs often outweigh the benefits of runtime flexibility.

Code-Based Configuration: The Type-Safe Standard

The Philosophy:

Code-based configuration represents a philosophical shift: configuration IS code. Rather than treating configuration as a separate concern requiring separate language (XML), it embraces the full power of the programming language:

Type checking catches errors at compile time
IDEs provide full navigation, refactoring, and auto-completion
Conditional logic uses native language constructs
Configuration can be unit tested like any other code
Version control diffs show meaningful changes

This approach dominates modern development because it reduces the cognitive overhead of maintaining two mental models (code + configuration).

ServiceConfiguration.cs
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
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
// Modern C# configuration with Microsoft.Extensions.DependencyInjection
// Demonstrating the full power of code-based configuration
 
public static class ServiceConfiguration
{
    public static IServiceCollection ConfigureApplication(
        this IServiceCollection services,
        IConfiguration configuration,
        IWebHostEnvironment environment)
    {
        // ------------------------------------------
        // Infrastructure Layer
        // ------------------------------------------
        
        // Conditional registration based on environment
        if (environment.IsDevelopment())
        {
            services.AddSingleton<ILogger, ColoredConsoleLogger>();
            services.AddSingleton<ICache, InMemoryCache>();
        }
        else if (environment.IsStaging())
        {
            services.AddSingleton<ILogger, JsonConsoleLogger>();
            services.AddSingleton<ICache>(sp => 
                new RedisCache(configuration["Redis:ConnectionString"]!));
        }
        else // Production
        {
            services.AddSingleton<ILogger, CloudWatchLogger>();
            services.AddSingleton<ICache>(sp => 
                new ElastiCacheClient(configuration["ElastiCache:Endpoint"]!));
        }
        
        // Database with connection string from configuration
        services.AddSingleton<IDatabase>(sp =>
        {
            var connectionString = configuration.GetConnectionString("Default")
                ?? throw new InvalidOperationException(
                    "Database connection string 'Default' not configured");
            var logger = sp.GetRequiredService<ILogger>();
            return new PostgresDatabase(connectionString, logger);
        });
        
        // ------------------------------------------
        // Repository Layer with Decorators
        // ------------------------------------------
        
        // Base repository
        services.AddScoped<UserRepository>();
        
        // Decorated repository with caching and logging
        services.AddScoped<IUserRepository>(sp =>
        {
            var baseRepo = sp.GetRequiredService<UserRepository>();
            var cache = sp.GetRequiredService<ICache>();
            var logger = sp.GetRequiredService<ILogger>();
            
            // Decorator chain: Logging -> Caching -> Base
            IUserRepository decorated = baseRepo;
            decorated = new CachingUserRepositoryDecorator(decorated, cache);
            decorated = new LoggingUserRepositoryDecorator(decorated, logger);
            
            return decorated;
        });
        
        services.AddScoped<IOrderRepository, OrderRepository>();
        services.AddScoped<IProductRepository, ProductRepository>();
        
        // ------------------------------------------
        // Service Layer
        // ------------------------------------------
        
        services.AddSingleton<IPasswordHasher>(sp =>
            new BcryptPasswordHasher(workFactor: 12));
        
        services.AddSingleton<ITokenService>(sp =>
        {
            var secret = configuration["Jwt:Secret"]
                ?? throw new InvalidOperationException("JWT secret not configured");
            var expiration = configuration.GetValue<int>("Jwt:ExpirationMinutes", 60);
            return new JwtTokenService(secret, expiration);
        });
        
        services.AddScoped<IUserService, UserService>();
        services.AddScoped<IOrderService, OrderService>();
        
        // ------------------------------------------
        // Feature Flags and Conditional Features
        // ------------------------------------------
        
        var features = configuration.GetSection("Features").Get<FeatureFlags>()
            ?? new FeatureFlags();
        
        if (features.NewPaymentGateway)
        {
            services.AddSingleton<IPaymentGateway, StripePaymentGateway>();
        }
        else
        {
            services.AddSingleton<IPaymentGateway, LegacyPaymentGateway>();
        }
        
        if (features.AsyncNotifications)
        {
            services.AddSingleton<INotificationService, QueuedNotificationService>();
        }
        else
        {
            services.AddSingleton<INotificationService, SyncNotificationService>();
        }
        
        // ------------------------------------------
        // Event Handlers (Multiple Registrations)
        // ------------------------------------------
        
        services.AddTransient<IEventHandler<UserCreated>, SendWelcomeEmailHandler>();
        services.AddTransient<IEventHandler<UserCreated>, CreateDefaultProfileHandler>();
        services.AddTransient<IEventHandler<UserCreated>, TrackSignupAnalyticsHandler>();
        
        services.AddTransient<IEventHandler<OrderPlaced>, SendOrderConfirmationHandler>();
        services.AddTransient<IEventHandler<OrderPlaced>, UpdateInventoryHandler>();
        services.AddTransient<IEventHandler<OrderPlaced>, NotifyWarehouseHandler>();
        
        // ------------------------------------------
        // Validation
        // ------------------------------------------
        
        services.AddTransient<IValidator<CreateUserCommand>, CreateUserValidator>();
        services.AddTransient<IValidator<PlaceOrderCommand>, PlaceOrderValidator>();
        
        return services;
    }
    
    // Separate method for testing with different configuration
    public static IServiceCollection ConfigureForTesting(
        this IServiceCollection services)
    {
        services.AddSingleton<ILogger, NullLogger>();
        services.AddSingleton<ICache, InMemoryCache>();
        services.AddSingleton<IDatabase, InMemoryDatabase>();
        // ... test doubles for all external dependencies
        
        return services;
    }
}
 
// Usage in Program.cs
var builder = WebApplication.CreateBuilder(args);
 
builder.Services.ConfigureApplication(
    builder.Configuration, 
    builder.Environment
);
 
var app = builder.Build();

Why Code Configuration Dominates

•Immediate feedback — Know at compile time if a registration references a non-existent type, has wrong constructor parameters, or mismatches interfaces.
•Refactoring confidence — Rename UserService to UserAccountService, and all registrations update automatically with IDE refactoring.
•Natural conditionals — if (environment.IsDevelopment()) reads naturally; XML conditions are awkward Spring Expression Language or separate profiles.
•Testability — Write unit tests that verify your container configuration actually resolves all expected services.
•Discoverability — 'Find all references' shows every place a type is registered; XML requires text search.
•Debugging — Set breakpoints in factory methods, inspect service provider state, understand exactly what's happening.

Attribute-Based Configuration: Self-Describing Classes

The Philosophy:

Attribute-based (or annotation-based in Java) configuration takes a different approach: classes describe their own registration requirements. Rather than maintaining a separate configuration location, the class itself declares:

That it should be registered with the container
What scope/lifetime it requires
Any special naming or tagging

This approach is particularly popular in frameworks like Spring (with @Component, @Service, etc.) and .NET's attribute-based libraries.

AttributeBasedRegistration.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
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
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
// Spring's attribute (annotation) based configuration
// Classes self-register via stereotype annotations
 
// Core component scan enables auto-discovery
@Configuration
@ComponentScan(basePackages = "com.example")
public class ApplicationConfig {
    // Component scanning discovers all @Component-annotated classes
    // in the specified packages and registers them automatically
}
 
// -------------------------------------------
// Infrastructure Layer
// -------------------------------------------
 
@Component  // Generic component
@Scope("singleton")
public class ConsoleLogger implements Logger {
    
    private final String prefix;
    
    public ConsoleLogger(
        @Value("${logging.prefix:[APP]}") String prefix
    ) {
        this.prefix = prefix;
    }
    
    @Override
    public void log(String message) {
        System.out.println(prefix + " " + message);
    }
}
 
@Repository  // Specialized stereotype for data access
@Scope("prototype")
public class UserRepositoryImpl implements UserRepository {
    
    private final Database database;
    private final Logger logger;
    
    @Autowired  // Constructor injection (optional in Spring 4.3+)
    public UserRepositoryImpl(Database database, Logger logger) {
        this.database = database;
        this.logger = logger;
    }
    
    @Override
    public Optional<User> findById(String id) {
        logger.log("Finding user: " + id);
        // Implementation
        return Optional.empty();
    }
    
    @Override
    @Cacheable(value = "users", key = "#id")  // Declarative caching
    public User findByIdCached(String id) {
        return findById(id).orElseThrow();
    }
}
 
// -------------------------------------------
// Service Layer
// -------------------------------------------
 
@Service  // Specialized stereotype for business logic
@Scope("request")
public class UserServiceImpl implements UserService {
    
    private final UserRepository userRepository;
    private final PasswordHasher passwordHasher;
    private final EventPublisher eventPublisher;
    private final Logger logger;
    
    @Autowired
    public UserServiceImpl(
        UserRepository userRepository,
        PasswordHasher passwordHasher,
        EventPublisher eventPublisher,
        Logger logger
    ) {
        this.userRepository = userRepository;
        this.passwordHasher = passwordHasher;
        this.eventPublisher = eventPublisher;
        this.logger = logger;
    }
    
    @Override
    @Transactional  // Declarative transaction management
    @Validated      // Enable validation
    public User createUser(@Valid CreateUserCommand command) {
        logger.log("Creating user: " + command.getEmail());
        
        User user = new User(
            UUID.randomUUID().toString(),
            command.getName(),
            command.getEmail(),
            passwordHasher.hash(command.getPassword())
        );
        
        userRepository.save(user);
        eventPublisher.publish(new UserCreated(user.getId()));
        
        return user;
    }
}
 
// -------------------------------------------
// Conditional Registration
// -------------------------------------------
 
@Component
@Profile("development")  // Only registered in development profile
public class DevOnlyDebugService implements DebugService {
    @Override
    public void dumpState() {
        // Implementation for development debugging
    }
}
 
@Component
@Profile("production")
public class ProductionDebugService implements DebugService {
    @Override
    public void dumpState() {
        // No-op or secured implementation for production
    }
}
 
// -------------------------------------------
// Multiple Implementations with Qualifiers
// -------------------------------------------
 
public interface NotificationChannel {
    void send(String userId, Notification notification);
}
 
@Component
@Qualifier("email")
public class EmailNotificationChannel implements NotificationChannel {
    @Override
    public void send(String userId, Notification notification) {
        // Send via email
    }
}
 
@Component
@Qualifier("sms")
public class SmsNotificationChannel implements NotificationChannel {
    @Override
    public void send(String userId, Notification notification) {
        // Send via SMS
    }
}
 
@Component
@Qualifier("push")
public class PushNotificationChannel implements NotificationChannel {
    @Override
    public void send(String userId, Notification notification) {
        // Send via push notification
    }
}
 
// Injection with qualifiers
@Service
public class MultiChannelNotificationService {
    
    private final NotificationChannel emailChannel;
    private final NotificationChannel smsChannel;
    private final NotificationChannel pushChannel;
    
    @Autowired
    public MultiChannelNotificationService(
        @Qualifier("email") NotificationChannel emailChannel,
        @Qualifier("sms") NotificationChannel smsChannel,
        @Qualifier("push") NotificationChannel pushChannel
    ) {
        this.emailChannel = emailChannel;
        this.smsChannel = smsChannel;
        this.pushChannel = pushChannel;
    }
}
 
// -------------------------------------------
// Primary Selection
// -------------------------------------------
 
@Component
@Primary  // Default implementation when no qualifier specified
public class DefaultPaymentGateway implements PaymentGateway {
    // Primary implementation
}
 
@Component
@Qualifier("legacy")
public class LegacyPaymentGateway implements PaymentGateway {
    // Legacy implementation for specific use cases
}

Attribute Configuration Advantages

•Self-documenting — Looking at a class immediately reveals its registration characteristics
•Reduced configuration code — No separate registration statements needed
•Consistency enforcement — Attributes ensure all services follow the same patterns
•Framework integration — Deeply integrated with frameworks like Spring that understand these stereotypes
•Discoverability — Find all services by searching for attributes

Attribute Configuration Disadvantages

•Scattered configuration — Registration info spread across many files, not centralized
•Limited conditional logic — Switching implementations requires profile mechanisms, not simple if/else
•Framework coupling — Classes become dependent on DI framework annotations
•Third-party limitation — Cannot annotate classes from external libraries
•Invisible magic — Component scanning can register unexpected classes

The Intrusive vs Non-Intrusive Trade-off

Attribute-based configuration is intrusive—it modifies your domain classes with DI framework concerns. This violates the principle that business logic should be framework-agnostic. However, this intrusion buys convenience and self-documentation. Many teams accept this trade-off for application-layer services while keeping domain entities attribute-free.

Comparative Analysis: Choosing Your Approach

Having examined each paradigm in depth, let's synthesize the key differentiators across dimensions that matter in real-world systems:

Configuration Paradigm Comparison Matrix
Dimension	XML	Code-Based	Attribute-Based
Type Safety	❌ None (strings)	✅ Full compile-time	✅ Compile-time
IDE Support	⚠️ Schema-based only	✅ Full refactoring	✅ Full refactoring
Centralization	✅ Single/few files	✅ Composition Root	❌ Scattered across classes
Runtime Flexibility	✅ Change without rebuild	❌ Requires recompilation	❌ Requires recompilation
Conditional Logic	⚠️ Limited/awkward	✅ Native language	⚠️ Profiles/qualifiers
Debugging	❌ Opaque errors	✅ Breakpoints/stepping	⚠️ Scanning logic hidden
Testability	❌ Not easily testable	✅ Unit testable	⚠️ Requires assembly scanning
Learning Curve	⚠️ XML schema learning	✅ Uses known language	⚠️ Framework-specific annotations
Third-Party Classes	✅ Can configure	✅ Can configure	❌ Cannot annotate
Framework Coupling	❌ Container-specific XML	⚠️ Container API in root	❌ Annotations in classes

The Decision Framework:

Choosing between configuration approaches isn't about finding the 'best' one—it's about matching the approach to your specific context:

When to Choose Each Approach

•Choose XML when: (1) Operations must reconfigure without developer involvement, (2) Existing systems mandate XML for consistency, (3) Plugin architectures where extensions are configured externally, (4) Compliance requires configuration artifact separation.
•Choose Code-Based when: (1) Developer experience and productivity are priorities, (2) Complex conditional registration logic is needed, (3) Team values type safety and refactoring support, (4) Testing configuration logic is important, (5) Starting a new project (this is the default recommendation).
•Choose Attribute-Based when: (1) Using Spring or similar frameworks with deep stereotype support, (2) Team prefers self-documenting classes over centralized configuration, (3) Simple applications with straightforward registration needs, (4) Convention over configuration is a team value.

Hybrid Approaches: The Pragmatic Reality

In practice, most production systems don't use a single configuration approach exclusively. Hybrid configurations combine the strengths of multiple paradigms:

Code + External Config: Structure (which types fulfill which interfaces) in code; values (connection strings, timeouts, feature flags) in environment variables or JSON files
Attributes + Code: Common registrations via scanning/attributes; special cases with explicit code configuration
Legacy Migration: XML for existing components during migration; code for new components

HybridConfiguration.ts
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
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
// Hybrid configuration: Code structure + External configuration values
// Best of both worlds
 
interface ExternalConfig {
    // Values that genuinely vary across deployments
    database: {
        connectionString: string;
        maxPoolSize: number;
        idleTimeoutMs: number;
    };
    redis: {
        host: string;
        port: number;
        password?: string;
    };
    jwt: {
        secret: string;
        expirationMinutes: number;
    };
    features: {
        newPaymentGateway: boolean;
        asyncNotifications: boolean;
        experimentalSearch: boolean;
    };
    logging: {
        level: 'debug' | 'info' | 'warn' | 'error';
        destination: 'console' | 'cloudwatch' | 'datadog';
    };
}
 
// Load external config from environment/files
function loadExternalConfig(): ExternalConfig {
    return {
        database: {
            connectionString: process.env.DATABASE_URL!,
            maxPoolSize: parseInt(process.env.DB_POOL_SIZE || '10'),
            idleTimeoutMs: parseInt(process.env.DB_IDLE_TIMEOUT || '30000'),
        },
        redis: {
            host: process.env.REDIS_HOST || 'localhost',
            port: parseInt(process.env.REDIS_PORT || '6379'),
            password: process.env.REDIS_PASSWORD,
        },
        jwt: {
            secret: process.env.JWT_SECRET!,
            expirationMinutes: parseInt(process.env.JWT_EXPIRATION || '60'),
        },
        features: {
            newPaymentGateway: process.env.FEATURE_NEW_PAYMENT === 'true',
            asyncNotifications: process.env.FEATURE_ASYNC_NOTIFICATIONS === 'true',
            experimentalSearch: process.env.FEATURE_EXPERIMENTAL_SEARCH === 'true',
        },
        logging: {
            level: (process.env.LOG_LEVEL as any) || 'info',
            destination: (process.env.LOG_DESTINATION as any) || 'console',
        },
    };
}
 
// Code-based configuration with external values
class HybridContainerBuilder {
    private container: Container;
    private config: ExternalConfig;
    
    constructor() {
        this.container = new Container();
        this.config = loadExternalConfig();
        this.validateConfig();
    }
    
    build(): Container {
        // Structure is in code (compile-time safe)
        // Values come from external config (deployment-time flexible)
        
        // Logger - destination from config, structure in code
        this.configureLogger();
        
        // Database - connection from config, implementation in code
        this.configureDatabase();
        
        // Features - flags from config, implementations in code
        this.configureFeatures();
        
        // Standard services - purely code
        this.configureServices();
        
        return this.container;
    }
    
    private configureLogger(): void {
        const { level, destination } = this.config.logging;
        
        // Structure: which logger types exist (code)
        // Choice: which to use (config)
        switch (destination) {
            case 'console':
                this.container.bind<ILogger>(TYPES.ILogger)
                    .toDynamicValue(() => new ConsoleLogger({ level }))
                    .inSingletonScope();
                break;
            case 'cloudwatch':
                this.container.bind<ILogger>(TYPES.ILogger)
                    .toDynamicValue(() => new CloudWatchLogger({ 
                        level,
                        logGroup: process.env.CLOUDWATCH_LOG_GROUP!,
                    }))
                    .inSingletonScope();
                break;
            case 'datadog':
                this.container.bind<ILogger>(TYPES.ILogger)
                    .toDynamicValue(() => new DatadogLogger({
                        level,
                        apiKey: process.env.DATADOG_API_KEY!,
                    }))
                    .inSingletonScope();
                break;
        }
    }
    
    private configureDatabase(): void {
        // Connection parameters from external config
        // Implementation choice in code
        const { connectionString, maxPoolSize, idleTimeoutMs } = this.config.database;
        
        this.container.bind<IDatabase>(TYPES.IDatabase)
            .toDynamicValue(ctx => {
                const logger = ctx.container.get<ILogger>(TYPES.ILogger);
                return new PostgresDatabase({
                    connectionString,
                    maxPoolSize,
                    idleTimeoutMs,
                    logger,
                });
            })
            .inSingletonScope();
    }
    
    private configureFeatures(): void {
        // Feature flags from external config
        // Implementation alternatives in code
        const { features } = this.config;
        
        if (features.newPaymentGateway) {
            this.container.bind<IPaymentGateway>(TYPES.IPaymentGateway)
                .to(StripePaymentGateway)
                .inSingletonScope();
        } else {
            this.container.bind<IPaymentGateway>(TYPES.IPaymentGateway)
                .to(LegacyPaymentGateway)
                .inSingletonScope();
        }
        
        if (features.experimentalSearch) {
            this.container.bind<ISearchService>(TYPES.ISearchService)
                .to(ElasticsearchService)
                .inSingletonScope();
        } else {
            this.container.bind<ISearchService>(TYPES.ISearchService)
                .to(PostgresFullTextSearchService)
                .inSingletonScope();
        }
    }
    
    private configureServices(): void {
        // Pure code configuration - no external values needed
        this.container.bind<IUserRepository>(TYPES.IUserRepository)
            .to(UserRepository)
            .inRequestScope();
        
        this.container.bind<IUserService>(TYPES.IUserService)
            .to(UserService)
            .inRequestScope();
        
        // ... additional services
    }
    
    private validateConfig(): void {
        const required = [
            ['database.connectionString', this.config.database.connectionString],
            ['jwt.secret', this.config.jwt.secret],
        ];
        
        const missing = required
            .filter(([_, value]) => !value)
            .map(([name]) => name);
        
        if (missing.length > 0) {
            throw new ConfigurationError(
                `Missing required configuration: ${missing.join(', ')}`
            );
        }
    }
}

The Pragmatic Rule

Structure in code, values in config. Keep the object graph structure (which interfaces map to which implementations) in code where it gets type-checked and refactoring support. Put values that genuinely vary across deployments (connection strings, secrets, feature flags) in external configuration. This hybrid gives you type safety AND deployment flexibility.

Summary: Configuration Paradigms

We've thoroughly analyzed the three major configuration paradigms. Here are the essential takeaways:

Key Takeaways

•XML configuration offers runtime flexibility but sacrifices type safety, IDE support, and debuggability. Use when non-developers must modify configuration without code changes.
•Code-based configuration is the modern default. It leverages your programming language's full power for type safety, refactoring, conditional logic, and testing.
•Attribute-based configuration provides self-documenting classes but scatters configuration and couples classes to the DI framework. Popular with Spring and convention-over-configuration philosophies.
•No paradigm is universally best—match the approach to your team, system requirements, and organizational constraints.
•Hybrid approaches are common and pragmatic—structure in code, variable values in external configuration.

What's Next:

With configuration paradigms understood, the next page explores Automatic Registration Patterns—convention-based approaches that reduce boilerplate by automatically discovering and registering services based on naming conventions, namespaces, and assembly scanning.

Page Complete

You now have a comprehensive understanding of XML, code-based, and attribute-based configuration paradigms. You can evaluate existing systems, migrate between approaches, and make principled decisions for new projects based on your specific requirements and constraints.

2 / 4

Loading learning content...

System Design (LLD)IoC Container Deep Dive

IoC Container Deep Dive

LevelIntermediate

Duration60 mins

TopicIoC Container Deep Dive

2 / 4

XML vs Code vs Attribute Configuration

The Three Configuration Paradigms

IoC container configuration has evolved through distinct paradigms, each reflecting the software development philosophy of its era:

XML Configuration — The original approach, born from Java's enterprise traditions and .NET's early frameworks
Code-Based Configuration — The modern dominant approach, prioritizing type safety and tooling
Attribute-Based Configuration — A declarative approach that embeds configuration in the classes themselves

What You Will Learn

XML Configuration: The Declarative Pioneer

The Philosophy:

XML configuration emerged from a fundamental premise: configuration should be separate from code. In the early 2000s, this separation was seen as essential for enterprise applications where:

Operations teams deployed applications without access to source code
Configuration needed to change without recompilation
Multiple environments (dev, staging, production) required different object wiring
External parties customized behavior through configuration files

XML provided a structured, validated, tool-supported format for expressing dependency graphs externally.

application-context.xml
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
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans.xsd">
 
    <!-- Infrastructure Layer -->
    
    <!-- Logger configuration with environment-based selection -->
    <bean id="logger" class="com.example.logging.ConsoleLogger" 
          scope="singleton">
        <constructor-arg name="prefix" value="[APP]"/>
        <constructor-arg name="level" value="${logging.level:INFO}"/>
    </bean>
    
    <!-- Database with connection pooling -->
    <bean id="dataSource" class="com.zaxxer.hikari.HikariDataSource"
          destroy-method="close" scope="singleton">
        <property name="jdbcUrl" value="${database.url}"/>
        <property name="username" value="${database.username}"/>
        <property name="password" value="${database.password}"/>
        <property name="maximumPoolSize" value="10"/>
        <property name="minimumIdle" value="2"/>
    </bean>
    
    <bean id="database" class="com.example.persistence.PostgresDatabase"
          scope="singleton">
        <constructor-arg ref="dataSource"/>
        <constructor-arg ref="logger"/>
    </bean>
    
    <!-- Caching with Redis -->
    <bean id="redisConnectionFactory" 
          class="org.springframework.data.redis.connection.jedis.JedisConnectionFactory"
          scope="singleton">
        <property name="hostName" value="${redis.host:localhost}"/>
        <property name="port" value="${redis.port:6379}"/>
    </bean>
    
    <bean id="cache" class="com.example.caching.RedisCache"
          scope="singleton">
        <constructor-arg ref="redisConnectionFactory"/>
        <constructor-arg name="defaultTtl" value="300"/>
    </bean>
    
    <!-- Repository Layer -->
    
    <bean id="userRepository" class="com.example.repository.UserRepositoryImpl"
          scope="prototype">
        <constructor-arg ref="database"/>
        <constructor-arg ref="logger"/>
    </bean>
    
    <!-- Add caching decorator -->
    <bean id="cachedUserRepository" 
          class="com.example.repository.CachingUserRepositoryDecorator"
          scope="prototype">
        <constructor-arg ref="userRepository"/>
        <constructor-arg ref="cache"/>
        <property name="ttlSeconds" value="600"/>
    </bean>
    
    <bean id="orderRepository" class="com.example.repository.OrderRepositoryImpl"
          scope="prototype">
        <constructor-arg ref="database"/>
        <constructor-arg ref="logger"/>
    </bean>
    
    <!-- Service Layer -->
    
    <bean id="passwordHasher" 
          class="com.example.security.BcryptPasswordHasher"
          scope="singleton">
        <constructor-arg name="workFactor" value="12"/>
    </bean>
    
    <bean id="tokenService" 
          class="com.example.security.JwtTokenService"
          scope="singleton">
        <constructor-arg name="secretKey" value="${jwt.secret}"/>
        <constructor-arg name="expirationMinutes" value="${jwt.expiration:60}"/>
    </bean>
    
    <bean id="userService" class="com.example.service.UserServiceImpl"
          scope="request">
        <constructor-arg ref="cachedUserRepository"/>
        <constructor-arg ref="passwordHasher"/>
        <constructor-arg ref="tokenService"/>
        <constructor-arg ref="logger"/>
    </bean>
    
    <bean id="orderService" class="com.example.service.OrderServiceImpl"
          scope="request">
        <constructor-arg ref="orderRepository"/>
        <constructor-arg ref="userService"/>
        <constructor-arg ref="logger"/>
    </bean>
    
    <!-- Payment processing with factory method -->
    <bean id="paymentGatewayFactory" 
          class="com.example.payment.PaymentGatewayFactory"
          scope="singleton"/>
    
    <bean id="paymentGateway" 
          factory-bean="paymentGatewayFactory"
          factory-method="createGateway"
          scope="singleton">
        <constructor-arg value="${payment.provider:stripe}"/>
        <constructor-arg value="${payment.api.key}"/>
    </bean>
    
    <!-- Notification channels -->
    <bean id="emailSender" class="com.example.notification.SendGridEmailSender"
          scope="singleton">
        <property name="apiKey" value="${sendgrid.api.key}"/>
        <property name="fromAddress" value="${notification.email.from}"/>
    </bean>
    
    <bean id="smsSender" class="com.example.notification.TwilioSmsSender"
          scope="singleton">
        <property name="accountSid" value="${twilio.account.sid}"/>
        <property name="authToken" value="${twilio.auth.token}"/>
        <property name="fromNumber" value="${twilio.from.number}"/>
    </bean>
    
    <!-- Import modular configurations -->
    <import resource="security-context.xml"/>
    <import resource="messaging-context.xml"/>
    
</beans>

XML Configuration Advantages

•Runtime flexibility — Change implementations without recompilation by editing XML files
•Environment separation — Deploy same binary with different configuration per environment
•Schema validation — XML schemas catch configuration errors before runtime
•Non-developer access — Operations teams can modify behavior without code access
•Tooling support — Many IDEs provide XML editing with auto-completion for known schemas
•Modular imports — Split configuration across multiple files and compose

XML Configuration Disadvantages

•No compile-time type safety — Typos in class names become runtime errors
•Verbose and repetitive — Simple registrations require significant boilerplate
•Refactoring blind spots — Rename a class and XML references silently break
•Limited conditional logic — Complex registration decisions are awkward or impossible
•Debugging difficulty — Cannot step through configuration; errors often opaque
•Testing challenges — XML configuration is not easily unit testable

The String Typing Problem

Code-Based Configuration: The Type-Safe Standard

The Philosophy:

Type checking catches errors at compile time
IDEs provide full navigation, refactoring, and auto-completion
Conditional logic uses native language constructs
Configuration can be unit tested like any other code
Version control diffs show meaningful changes

This approach dominates modern development because it reduces the cognitive overhead of maintaining two mental models (code + configuration).

ServiceConfiguration.cs
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
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
// Modern C# configuration with Microsoft.Extensions.DependencyInjection
// Demonstrating the full power of code-based configuration
 
public static class ServiceConfiguration
{
    public static IServiceCollection ConfigureApplication(
        this IServiceCollection services,
        IConfiguration configuration,
        IWebHostEnvironment environment)
    {
        // ------------------------------------------
        // Infrastructure Layer
        // ------------------------------------------
        
        // Conditional registration based on environment
        if (environment.IsDevelopment())
        {
            services.AddSingleton<ILogger, ColoredConsoleLogger>();
            services.AddSingleton<ICache, InMemoryCache>();
        }
        else if (environment.IsStaging())
        {
            services.AddSingleton<ILogger, JsonConsoleLogger>();
            services.AddSingleton<ICache>(sp => 
                new RedisCache(configuration["Redis:ConnectionString"]!));
        }
        else // Production
        {
            services.AddSingleton<ILogger, CloudWatchLogger>();
            services.AddSingleton<ICache>(sp => 
                new ElastiCacheClient(configuration["ElastiCache:Endpoint"]!));
        }
        
        // Database with connection string from configuration
        services.AddSingleton<IDatabase>(sp =>
        {
            var connectionString = configuration.GetConnectionString("Default")
                ?? throw new InvalidOperationException(
                    "Database connection string 'Default' not configured");
            var logger = sp.GetRequiredService<ILogger>();
            return new PostgresDatabase(connectionString, logger);
        });
        
        // ------------------------------------------
        // Repository Layer with Decorators
        // ------------------------------------------
        
        // Base repository
        services.AddScoped<UserRepository>();
        
        // Decorated repository with caching and logging
        services.AddScoped<IUserRepository>(sp =>
        {
            var baseRepo = sp.GetRequiredService<UserRepository>();
            var cache = sp.GetRequiredService<ICache>();
            var logger = sp.GetRequiredService<ILogger>();
            
            // Decorator chain: Logging -> Caching -> Base
            IUserRepository decorated = baseRepo;
            decorated = new CachingUserRepositoryDecorator(decorated, cache);
            decorated = new LoggingUserRepositoryDecorator(decorated, logger);
            
            return decorated;
        });
        
        services.AddScoped<IOrderRepository, OrderRepository>();
        services.AddScoped<IProductRepository, ProductRepository>();
        
        // ------------------------------------------
        // Service Layer
        // ------------------------------------------
        
        services.AddSingleton<IPasswordHasher>(sp =>
            new BcryptPasswordHasher(workFactor: 12));
        
        services.AddSingleton<ITokenService>(sp =>
        {
            var secret = configuration["Jwt:Secret"]
                ?? throw new InvalidOperationException("JWT secret not configured");
            var expiration = configuration.GetValue<int>("Jwt:ExpirationMinutes", 60);
            return new JwtTokenService(secret, expiration);
        });
        
        services.AddScoped<IUserService, UserService>();
        services.AddScoped<IOrderService, OrderService>();
        
        // ------------------------------------------
        // Feature Flags and Conditional Features
        // ------------------------------------------
        
        var features = configuration.GetSection("Features").Get<FeatureFlags>()
            ?? new FeatureFlags();
        
        if (features.NewPaymentGateway)
        {
            services.AddSingleton<IPaymentGateway, StripePaymentGateway>();
        }
        else
        {
            services.AddSingleton<IPaymentGateway, LegacyPaymentGateway>();
        }
        
        if (features.AsyncNotifications)
        {
            services.AddSingleton<INotificationService, QueuedNotificationService>();
        }
        else
        {
            services.AddSingleton<INotificationService, SyncNotificationService>();
        }
        
        // ------------------------------------------
        // Event Handlers (Multiple Registrations)
        // ------------------------------------------
        
        services.AddTransient<IEventHandler<UserCreated>, SendWelcomeEmailHandler>();
        services.AddTransient<IEventHandler<UserCreated>, CreateDefaultProfileHandler>();
        services.AddTransient<IEventHandler<UserCreated>, TrackSignupAnalyticsHandler>();
        
        services.AddTransient<IEventHandler<OrderPlaced>, SendOrderConfirmationHandler>();
        services.AddTransient<IEventHandler<OrderPlaced>, UpdateInventoryHandler>();
        services.AddTransient<IEventHandler<OrderPlaced>, NotifyWarehouseHandler>();
        
        // ------------------------------------------
        // Validation
        // ------------------------------------------
        
        services.AddTransient<IValidator<CreateUserCommand>, CreateUserValidator>();
        services.AddTransient<IValidator<PlaceOrderCommand>, PlaceOrderValidator>();
        
        return services;
    }
    
    // Separate method for testing with different configuration
    public static IServiceCollection ConfigureForTesting(
        this IServiceCollection services)
    {
        services.AddSingleton<ILogger, NullLogger>();
        services.AddSingleton<ICache, InMemoryCache>();
        services.AddSingleton<IDatabase, InMemoryDatabase>();
        // ... test doubles for all external dependencies
        
        return services;
    }
}
 
// Usage in Program.cs
var builder = WebApplication.CreateBuilder(args);
 
builder.Services.ConfigureApplication(
    builder.Configuration, 
    builder.Environment
);
 
var app = builder.Build();

Why Code Configuration Dominates

•Immediate feedback — Know at compile time if a registration references a non-existent type, has wrong constructor parameters, or mismatches interfaces.
•Refactoring confidence — Rename UserService to UserAccountService, and all registrations update automatically with IDE refactoring.
•Natural conditionals — if (environment.IsDevelopment()) reads naturally; XML conditions are awkward Spring Expression Language or separate profiles.
•Testability — Write unit tests that verify your container configuration actually resolves all expected services.
•Discoverability — 'Find all references' shows every place a type is registered; XML requires text search.
•Debugging — Set breakpoints in factory methods, inspect service provider state, understand exactly what's happening.

Attribute-Based Configuration: Self-Describing Classes

The Philosophy:

That it should be registered with the container
What scope/lifetime it requires
Any special naming or tagging

This approach is particularly popular in frameworks like Spring (with @Component, @Service, etc.) and .NET's attribute-based libraries.

AttributeBasedRegistration.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
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
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
// Spring's attribute (annotation) based configuration
// Classes self-register via stereotype annotations
 
// Core component scan enables auto-discovery
@Configuration
@ComponentScan(basePackages = "com.example")
public class ApplicationConfig {
    // Component scanning discovers all @Component-annotated classes
    // in the specified packages and registers them automatically
}
 
// -------------------------------------------
// Infrastructure Layer
// -------------------------------------------
 
@Component  // Generic component
@Scope("singleton")
public class ConsoleLogger implements Logger {
    
    private final String prefix;
    
    public ConsoleLogger(
        @Value("${logging.prefix:[APP]}") String prefix
    ) {
        this.prefix = prefix;
    }
    
    @Override
    public void log(String message) {
        System.out.println(prefix + " " + message);
    }
}
 
@Repository  // Specialized stereotype for data access
@Scope("prototype")
public class UserRepositoryImpl implements UserRepository {
    
    private final Database database;
    private final Logger logger;
    
    @Autowired  // Constructor injection (optional in Spring 4.3+)
    public UserRepositoryImpl(Database database, Logger logger) {
        this.database = database;
        this.logger = logger;
    }
    
    @Override
    public Optional<User> findById(String id) {
        logger.log("Finding user: " + id);
        // Implementation
        return Optional.empty();
    }
    
    @Override
    @Cacheable(value = "users", key = "#id")  // Declarative caching
    public User findByIdCached(String id) {
        return findById(id).orElseThrow();
    }
}
 
// -------------------------------------------
// Service Layer
// -------------------------------------------
 
@Service  // Specialized stereotype for business logic
@Scope("request")
public class UserServiceImpl implements UserService {
    
    private final UserRepository userRepository;
    private final PasswordHasher passwordHasher;
    private final EventPublisher eventPublisher;
    private final Logger logger;
    
    @Autowired
    public UserServiceImpl(
        UserRepository userRepository,
        PasswordHasher passwordHasher,
        EventPublisher eventPublisher,
        Logger logger
    ) {
        this.userRepository = userRepository;
        this.passwordHasher = passwordHasher;
        this.eventPublisher = eventPublisher;
        this.logger = logger;
    }
    
    @Override
    @Transactional  // Declarative transaction management
    @Validated      // Enable validation
    public User createUser(@Valid CreateUserCommand command) {
        logger.log("Creating user: " + command.getEmail());
        
        User user = new User(
            UUID.randomUUID().toString(),
            command.getName(),
            command.getEmail(),
            passwordHasher.hash(command.getPassword())
        );
        
        userRepository.save(user);
        eventPublisher.publish(new UserCreated(user.getId()));
        
        return user;
    }
}
 
// -------------------------------------------
// Conditional Registration
// -------------------------------------------
 
@Component
@Profile("development")  // Only registered in development profile
public class DevOnlyDebugService implements DebugService {
    @Override
    public void dumpState() {
        // Implementation for development debugging
    }
}
 
@Component
@Profile("production")
public class ProductionDebugService implements DebugService {
    @Override
    public void dumpState() {
        // No-op or secured implementation for production
    }
}
 
// -------------------------------------------
// Multiple Implementations with Qualifiers
// -------------------------------------------
 
public interface NotificationChannel {
    void send(String userId, Notification notification);
}
 
@Component
@Qualifier("email")
public class EmailNotificationChannel implements NotificationChannel {
    @Override
    public void send(String userId, Notification notification) {
        // Send via email
    }
}
 
@Component
@Qualifier("sms")
public class SmsNotificationChannel implements NotificationChannel {
    @Override
    public void send(String userId, Notification notification) {
        // Send via SMS
    }
}
 
@Component
@Qualifier("push")
public class PushNotificationChannel implements NotificationChannel {
    @Override
    public void send(String userId, Notification notification) {
        // Send via push notification
    }
}
 
// Injection with qualifiers
@Service
public class MultiChannelNotificationService {
    
    private final NotificationChannel emailChannel;
    private final NotificationChannel smsChannel;
    private final NotificationChannel pushChannel;
    
    @Autowired
    public MultiChannelNotificationService(
        @Qualifier("email") NotificationChannel emailChannel,
        @Qualifier("sms") NotificationChannel smsChannel,
        @Qualifier("push") NotificationChannel pushChannel
    ) {
        this.emailChannel = emailChannel;
        this.smsChannel = smsChannel;
        this.pushChannel = pushChannel;
    }
}
 
// -------------------------------------------
// Primary Selection
// -------------------------------------------
 
@Component
@Primary  // Default implementation when no qualifier specified
public class DefaultPaymentGateway implements PaymentGateway {
    // Primary implementation
}
 
@Component
@Qualifier("legacy")
public class LegacyPaymentGateway implements PaymentGateway {
    // Legacy implementation for specific use cases
}

Attribute Configuration Advantages

•Self-documenting — Looking at a class immediately reveals its registration characteristics
•Reduced configuration code — No separate registration statements needed
•Consistency enforcement — Attributes ensure all services follow the same patterns
•Framework integration — Deeply integrated with frameworks like Spring that understand these stereotypes
•Discoverability — Find all services by searching for attributes

Attribute Configuration Disadvantages

•Scattered configuration — Registration info spread across many files, not centralized
•Limited conditional logic — Switching implementations requires profile mechanisms, not simple if/else
•Framework coupling — Classes become dependent on DI framework annotations
•Third-party limitation — Cannot annotate classes from external libraries
•Invisible magic — Component scanning can register unexpected classes

The Intrusive vs Non-Intrusive Trade-off

Comparative Analysis: Choosing Your Approach

Having examined each paradigm in depth, let's synthesize the key differentiators across dimensions that matter in real-world systems:

Configuration Paradigm Comparison Matrix
Dimension	XML	Code-Based	Attribute-Based
Type Safety	❌ None (strings)	✅ Full compile-time	✅ Compile-time
IDE Support	⚠️ Schema-based only	✅ Full refactoring	✅ Full refactoring
Centralization	✅ Single/few files	✅ Composition Root	❌ Scattered across classes
Runtime Flexibility	✅ Change without rebuild	❌ Requires recompilation	❌ Requires recompilation
Conditional Logic	⚠️ Limited/awkward	✅ Native language	⚠️ Profiles/qualifiers
Debugging	❌ Opaque errors	✅ Breakpoints/stepping	⚠️ Scanning logic hidden
Testability	❌ Not easily testable	✅ Unit testable	⚠️ Requires assembly scanning
Learning Curve	⚠️ XML schema learning	✅ Uses known language	⚠️ Framework-specific annotations
Third-Party Classes	✅ Can configure	✅ Can configure	❌ Cannot annotate
Framework Coupling	❌ Container-specific XML	⚠️ Container API in root	❌ Annotations in classes

The Decision Framework:

Choosing between configuration approaches isn't about finding the 'best' one—it's about matching the approach to your specific context:

When to Choose Each Approach

•Choose XML when: (1) Operations must reconfigure without developer involvement, (2) Existing systems mandate XML for consistency, (3) Plugin architectures where extensions are configured externally, (4) Compliance requires configuration artifact separation.
•Choose Code-Based when: (1) Developer experience and productivity are priorities, (2) Complex conditional registration logic is needed, (3) Team values type safety and refactoring support, (4) Testing configuration logic is important, (5) Starting a new project (this is the default recommendation).
•Choose Attribute-Based when: (1) Using Spring or similar frameworks with deep stereotype support, (2) Team prefers self-documenting classes over centralized configuration, (3) Simple applications with straightforward registration needs, (4) Convention over configuration is a team value.

Hybrid Approaches: The Pragmatic Reality

In practice, most production systems don't use a single configuration approach exclusively. Hybrid configurations combine the strengths of multiple paradigms:

Code + External Config: Structure (which types fulfill which interfaces) in code; values (connection strings, timeouts, feature flags) in environment variables or JSON files
Attributes + Code: Common registrations via scanning/attributes; special cases with explicit code configuration
Legacy Migration: XML for existing components during migration; code for new components

HybridConfiguration.ts
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
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
// Hybrid configuration: Code structure + External configuration values
// Best of both worlds
 
interface ExternalConfig {
    // Values that genuinely vary across deployments
    database: {
        connectionString: string;
        maxPoolSize: number;
        idleTimeoutMs: number;
    };
    redis: {
        host: string;
        port: number;
        password?: string;
    };
    jwt: {
        secret: string;
        expirationMinutes: number;
    };
    features: {
        newPaymentGateway: boolean;
        asyncNotifications: boolean;
        experimentalSearch: boolean;
    };
    logging: {
        level: 'debug' | 'info' | 'warn' | 'error';
        destination: 'console' | 'cloudwatch' | 'datadog';
    };
}
 
// Load external config from environment/files
function loadExternalConfig(): ExternalConfig {
    return {
        database: {
            connectionString: process.env.DATABASE_URL!,
            maxPoolSize: parseInt(process.env.DB_POOL_SIZE || '10'),
            idleTimeoutMs: parseInt(process.env.DB_IDLE_TIMEOUT || '30000'),
        },
        redis: {
            host: process.env.REDIS_HOST || 'localhost',
            port: parseInt(process.env.REDIS_PORT || '6379'),
            password: process.env.REDIS_PASSWORD,
        },
        jwt: {
            secret: process.env.JWT_SECRET!,
            expirationMinutes: parseInt(process.env.JWT_EXPIRATION || '60'),
        },
        features: {
            newPaymentGateway: process.env.FEATURE_NEW_PAYMENT === 'true',
            asyncNotifications: process.env.FEATURE_ASYNC_NOTIFICATIONS === 'true',
            experimentalSearch: process.env.FEATURE_EXPERIMENTAL_SEARCH === 'true',
        },
        logging: {
            level: (process.env.LOG_LEVEL as any) || 'info',
            destination: (process.env.LOG_DESTINATION as any) || 'console',
        },
    };
}
 
// Code-based configuration with external values
class HybridContainerBuilder {
    private container: Container;
    private config: ExternalConfig;
    
    constructor() {
        this.container = new Container();
        this.config = loadExternalConfig();
        this.validateConfig();
    }
    
    build(): Container {
        // Structure is in code (compile-time safe)
        // Values come from external config (deployment-time flexible)
        
        // Logger - destination from config, structure in code
        this.configureLogger();
        
        // Database - connection from config, implementation in code
        this.configureDatabase();
        
        // Features - flags from config, implementations in code
        this.configureFeatures();
        
        // Standard services - purely code
        this.configureServices();
        
        return this.container;
    }
    
    private configureLogger(): void {
        const { level, destination } = this.config.logging;
        
        // Structure: which logger types exist (code)
        // Choice: which to use (config)
        switch (destination) {
            case 'console':
                this.container.bind<ILogger>(TYPES.ILogger)
                    .toDynamicValue(() => new ConsoleLogger({ level }))
                    .inSingletonScope();
                break;
            case 'cloudwatch':
                this.container.bind<ILogger>(TYPES.ILogger)
                    .toDynamicValue(() => new CloudWatchLogger({ 
                        level,
                        logGroup: process.env.CLOUDWATCH_LOG_GROUP!,
                    }))
                    .inSingletonScope();
                break;
            case 'datadog':
                this.container.bind<ILogger>(TYPES.ILogger)
                    .toDynamicValue(() => new DatadogLogger({
                        level,
                        apiKey: process.env.DATADOG_API_KEY!,
                    }))
                    .inSingletonScope();
                break;
        }
    }
    
    private configureDatabase(): void {
        // Connection parameters from external config
        // Implementation choice in code
        const { connectionString, maxPoolSize, idleTimeoutMs } = this.config.database;
        
        this.container.bind<IDatabase>(TYPES.IDatabase)
            .toDynamicValue(ctx => {
                const logger = ctx.container.get<ILogger>(TYPES.ILogger);
                return new PostgresDatabase({
                    connectionString,
                    maxPoolSize,
                    idleTimeoutMs,
                    logger,
                });
            })
            .inSingletonScope();
    }
    
    private configureFeatures(): void {
        // Feature flags from external config
        // Implementation alternatives in code
        const { features } = this.config;
        
        if (features.newPaymentGateway) {
            this.container.bind<IPaymentGateway>(TYPES.IPaymentGateway)
                .to(StripePaymentGateway)
                .inSingletonScope();
        } else {
            this.container.bind<IPaymentGateway>(TYPES.IPaymentGateway)
                .to(LegacyPaymentGateway)
                .inSingletonScope();
        }
        
        if (features.experimentalSearch) {
            this.container.bind<ISearchService>(TYPES.ISearchService)
                .to(ElasticsearchService)
                .inSingletonScope();
        } else {
            this.container.bind<ISearchService>(TYPES.ISearchService)
                .to(PostgresFullTextSearchService)
                .inSingletonScope();
        }
    }
    
    private configureServices(): void {
        // Pure code configuration - no external values needed
        this.container.bind<IUserRepository>(TYPES.IUserRepository)
            .to(UserRepository)
            .inRequestScope();
        
        this.container.bind<IUserService>(TYPES.IUserService)
            .to(UserService)
            .inRequestScope();
        
        // ... additional services
    }
    
    private validateConfig(): void {
        const required = [
            ['database.connectionString', this.config.database.connectionString],
            ['jwt.secret', this.config.jwt.secret],
        ];
        
        const missing = required
            .filter(([_, value]) => !value)
            .map(([name]) => name);
        
        if (missing.length > 0) {
            throw new ConfigurationError(
                `Missing required configuration: ${missing.join(', ')}`
            );
        }
    }
}

The Pragmatic Rule

Summary: Configuration Paradigms

We've thoroughly analyzed the three major configuration paradigms. Here are the essential takeaways:

Key Takeaways

•XML configuration offers runtime flexibility but sacrifices type safety, IDE support, and debuggability. Use when non-developers must modify configuration without code changes.
•Code-based configuration is the modern default. It leverages your programming language's full power for type safety, refactoring, conditional logic, and testing.
•Attribute-based configuration provides self-documenting classes but scatters configuration and couples classes to the DI framework. Popular with Spring and convention-over-configuration philosophies.
•No paradigm is universally best—match the approach to your team, system requirements, and organizational constraints.
•Hybrid approaches are common and pragmatic—structure in code, variable values in external configuration.

What's Next:

Page Complete

2 / 4