45:"/_next/static/chunks/33yus346z0l_n.js" 46:"/_next/static/chunks/1r8ezocsukqp8.js" 47:"/_next/static/chunks/0iv56yrji_20j.js" 48:"/_next/static/chunks/0wa9m1-tphf9u.js" 49:"/_next/static/chunks/08cuqqn_f60pp.js" 4a:"/_next/static/chunks/3zdsl3f9b0--r.js" 4b:"/_next/static/chunks/2j22cxchii_xx.js" 4c:"/_next/static/chunks/3bgoyiso1rhn7.js" 4d:"/_next/static/chunks/01a-3hvnqu8wl.js" 4e:"/_next/static/chunks/3m1xjj5kw5fie.js" 4f:"/_next/static/chunks/0om3fkgfnicab.js" 50:"/_next/static/chunks/0gafyzg9j9yqj.js" 51:"/_next/static/chunks/20w4eaqlekefm.js" 52:"/_next/static/chunks/449--h5z1s6nq.js" 53:"/_next/static/chunks/3k2gyg36fnag_.js" 54:"/_next/static/chunks/18ggtgz2yf759.js" 55:"/_next/static/chunks/0hlb44ca7-4a2.js" 56:"/_next/static/chunks/253gnmj0-cj17.js" 57:"/_next/static/chunks/09nq57stwzkgf.js" 58:"/_next/static/chunks/082jo-0ajazgr.js" 59:"/_next/static/chunks/2ozcrjb_hh74t.js" 5a:"/_next/static/chunks/05i8en-x14ibi.js" 5b:"/_next/static/chunks/32izpn90gvm22.js" 5c:"/_next/static/chunks/0jbzid2v9xv3h.js" 5d:"/_next/static/chunks/0i3-eynrkvqi7.js" 5e:"/_next/static/chunks/1tn-0fivsxsv1.js" 5f:"/_next/static/chunks/34h36hyf_ggow.js" 60:"/_next/static/chunks/20329i6m_04t6.js" 61:"/_next/static/chunks/161uxd62cjny2.js" 62:"/_next/static/chunks/2k8pepwc4pxns.js" 63:I[593304,["$2b","$2c","$2d","$2e","$2f","$30","$45","$46","$47","$48","$49","$4a","$4b","$4c","$4d","$4e","$4f","$50","$51","$52","$53","$54","$55","$56","$57","$58","$59","$5a","$5b","$5c","$5d","$5e","$5f","$60","$61","$62"],"OwnedHydration"] 64:T41d,Throughout our exploration of the Dependency Inversion Principle, we've established that high-level modules should depend on abstractions, not concrete implementations. We've learned that dependency injection allows us to supply those dependencies from outside, making our code testable and flexible. But as applications grow in complexity, a fundamental question emerges: **Who creates and wires together all these objects?** Consider a real-world enterprise application. A single request might touch dozens of components: controllers, services, repositories, caches, validators, loggers, and external API clients. Each component might have five to ten dependencies. Those dependencies have their own dependencies. Manually constructing this object graph becomes a maintenance nightmare of exponential complexity. This is where **Inversion of Control (IoC) containers** enter the picture—not as mere convenience utilities, but as **architectural infrastructure** that fundamentally changes how enterprise applications are structured and maintained.65:T47e,Before diving into containers, we must understand the paradigm they implement: **Inversion of Control (IoC)**. This is a fundamental principle that extends far beyond dependency injection and represents a profound shift in how we structure software. **Traditional Control Flow:** In traditional procedural programming, your application code controls the flow of execution. Your code calls library functions when needed. Your code decides when to create objects. Your code determines the order of operations. The application is the active party; frameworks and libraries are passive tools waiting to be invoked. **Inverted Control Flow:** Under IoC, this relationship reverses. A framework takes control of the application flow. It calls your code at appropriate times. It creates objects when needed. It determines orchestration. Your code becomes the passive party—components that plug into a framework-controlled structure. This inversion isn't new. If you've ever written a callback function, implemented an event handler, or created a template method subclass, you've experienced IoC. The framework calls you; you don't call the framework.66:T419,IoC is a broad principle with many manifestations. **Dependency Injection** is one specific form of IoC—perhaps the most architecturally significant for application structure. And an **IoC container** is a specialized framework that automates dependency injection at scale. **Definition: IoC Container** An IoC container (also called a DI container or dependency injection container) is a framework component responsible for: 1. **Creating objects** — Instantiating classes when dependencies are needed 2. **Managing lifecycles** — Controlling when objects are created and destroyed 3. **Resolving dependencies** — Determining what concrete types satisfy abstract dependencies 4. **Wiring the object graph** — Connecting objects to their dependencies recursively The term 'container' reflects that all your application's managed objects 'live' within this framework. The container is aware of every registered component, their dependencies, and their configuration. It acts as a central registry and factory for the entire application.67:T51f,// Conceptual model of what an IoC container provides // (This is illustrative, not a real implementation) interface IoCContainer { /** * Register a type with the container. * When someone needs IService, give them ConcreteService. */ register( interfaceType: Constructor, concreteType: Constructor, lifecycle?: Lifecycle ): void; /** * Resolve a dependency. * The container creates the object and all its dependencies. */ resolve(type: Constructor): T; /** * Create a scope within which singleton-scoped objects live. * Useful for request-scoped dependencies in web apps. */ createScope(): IContainerScope; } // Usage conceptually looks like: container.register(ILogger, ConsoleLogger, Lifecycle.Singleton); container.register(IUserRepository, PostgresUserRepository, Lifecycle.Scoped); container.register(IUserService, UserService, Lifecycle.Transient); // When we need a UserService, the container: // 1. Creates a new UserService (transient) // 2. Resolves IUserRepository → creates/reuses PostgresUserRepository // 3. Resolves ILogger → reuses the singleton ConsoleLogger // 4. Injects all dependencies into constructors const userService = container.resolve(IUserService);68:T53b,// Conceptual model of what an IoC container provides // (This is illustrative, not a real implementation) public interface IIoCContainer { ///

/// Register a type with the container. /// When someone needs IService, give them ConcreteService. ///

void Register(Lifecycle lifecycle = Lifecycle.Transient) where TConcrete : TInterface; ///

/// Resolve a dependency. /// The container creates the object and all its dependencies. ///

T Resolve(); ///

/// Create a scope within which singleton-scoped objects live. /// Useful for request-scoped dependencies in web apps. ///

IContainerScope CreateScope(); } // Usage conceptually looks like: container.Register(Lifecycle.Singleton); container.Register(Lifecycle.Scoped); container.Register(Lifecycle.Transient); // When we need a UserService, the container: // 1. Creates a new UserService (transient) // 2. Resolves IUserRepository → creates/reuses PostgresUserRepository // 3. Resolves ILogger → reuses the singleton ConsoleLogger // 4. Injects all dependencies into constructors var userService = container.Resolve();69:T56a,// Conceptual model of what an IoC container provides // (This is illustrative, not a real implementation) public interface IoCContainer { /** * Register a type with the container. * When someone needs IService, give them ConcreteService. */ void register( Class interfaceType, Class concreteType, Lifecycle lifecycle ); /** * Resolve a dependency. * The container creates the object and all its dependencies. */ T resolve(Class type); /** * Create a scope within which singleton-scoped objects live. * Useful for request-scoped dependencies in web apps. */ ContainerScope createScope(); } // Usage conceptually looks like: container.register(ILogger.class, ConsoleLogger.class, Lifecycle.SINGLETON); container.register(IUserRepository.class, PostgresUserRepository.class, Lifecycle.SCOPED); container.register(IUserService.class, UserService.class, Lifecycle.TRANSIENT); // When we need a UserService, the container: // 1. Creates a new UserService (transient) // 2. Resolves IUserRepository → creates/reuses PostgresUserRepository // 3. Resolves ILogger → reuses the singleton ConsoleLogger // 4. Injects all dependencies into constructors IUserService userService = container.resolve(IUserService.class);6a:Te2d,// WITHOUT IOC CONTAINER: Manual Object Composition // This is the "composition root" - where we wire everything together function createApplication(): Application { // Infrastructure layer - must create first const config = new ConfigurationReader(); const connectionString = config.get("DATABASE_URL"); const logger = new ConsoleLogger(config.get("LOG_LEVEL")); const metricsClient = new PrometheusMetricsClient(config.get("METRICS_ENDPOINT")); // Data access layer - depends on infrastructure const dbConnection = new PostgresConnection(connectionString, logger); const userRepository = new PostgresUserRepository(dbConnection, logger); const orderRepository = new PostgresOrderRepository(dbConnection, logger); const productRepository = new PostgresProductRepository(dbConnection, logger); const inventoryRepository = new PostgresInventoryRepository(dbConnection, logger); // Caching layer - depends on infrastructure const redisClient = new RedisClient(config.get("REDIS_URL"), logger); const userCache = new RedisUserCache(redisClient, logger); const productCache = new RedisProductCache(redisClient, logger); // External services - depends on infrastructure const httpClient = new HttpClient(logger, metricsClient); const paymentGateway = new StripePaymentGateway( config.get("STRIPE_API_KEY"), httpClient, logger ); const emailService = new SendGridEmailService( config.get("SENDGRID_API_KEY"), httpClient, logger ); const notificationService = new NotificationService(emailService, logger); // Validation services const userValidator = new UserValidator(); const orderValidator = new OrderValidator(); const paymentValidator = new PaymentValidator(); // Business services - depends on everything above const userService = new UserService( userRepository, userCache, userValidator, logger, metricsClient ); const inventoryService = new InventoryService( inventoryRepository, productCache, logger, metricsClient ); const orderService = new OrderService( orderRepository, inventoryService, paymentGateway, orderValidator, notificationService, logger, metricsClient ); const checkoutService = new CheckoutService( userService, orderService, inventoryService, paymentValidator, logger, metricsClient ); // Controllers - depends on business services const userController = new UserController(userService, logger); const orderController = new OrderController(orderService, checkoutService, logger); const productController = new ProductController(inventoryService, logger); // Middleware const authMiddleware = new AuthenticationMiddleware(userService, logger); const loggingMiddleware = new LoggingMiddleware(logger); const metricsMiddleware = new MetricsMiddleware(metricsClient); // Router const router = new Router([ { path: "/users", controller: userController }, { path: "/orders", controller: orderController }, { path: "/products", controller: productController }, ]); // Application return new Application( router, [loggingMiddleware, metricsMiddleware, authMiddleware], logger ); } // PROBLEMS WITH THIS APPROACH: // 1. This function is 80+ lines and growing // 2. Order matters - PostgresConnection before PostgresUserRepository // 3. Adding one dependency changes this file // 4. Hard to test - can't easily swap implementations // 5. No lifecycle management - all singletons? Who knows? // 6. Configuration is interleaved with construction6b:T828,// LIFECYCLE MANAGEMENT EXAMPLES // SINGLETON: Created once, reused forever // Good for stateless infrastructure services container.register(Lifecycle.Singleton); container.register(Lifecycle.Singleton); container.register(Lifecycle.Singleton); // SCOPED: Created once per scope (e.g., HTTP request) // Good for stateful-per-request services container.register(Lifecycle.Scoped); container.register(Lifecycle.Scoped); container.register(Lifecycle.Scoped); // TRANSIENT: Created every time requested // Good for stateless operations and when fresh state is required container.register(Lifecycle.Transient); container.register(Lifecycle.Transient); container.register(Lifecycle.Transient); // ============================================ // CAPTIVE DEPENDENCY ANTI-PATTERN // ============================================ // ❌ WRONG: Singleton depends on Scoped class BadUserCache implements IUserCache { constructor( private dbContext: IDbContext // Scoped! Will be captured! ) {} getUser(id: string): User { // This dbContext was created for the first request // and will be reused incorrectly for all future requests return this.dbContext.users.findById(id); } } // ✅ CORRECT: Singleton depends on factory for scoped service class GoodUserCache implements IUserCache { constructor( private dbContextFactory: () => IDbContext // Factory function ) {} getUser(id: string): User { // Create fresh DbContext for each operation const dbContext = this.dbContextFactory(); try { return dbContext.users.findById(id); } finally { dbContext.dispose(); } } } // Registration with factory container.register( Lifecycle.Singleton, (resolver) => new GoodUserCache( () => resolver.resolve() ) );6c:Td2b,// COMPOSITION ROOT PATTERN // =============================================== // 1. Container Setup (Composition Root) // =============================================== // File: src/main.ts or src/composition-root.ts import { Container } from "./container"; import { InfrastructureModule } from "./modules/infrastructure.module"; import { DataAccessModule } from "./modules/data-access.module"; import { BusinessModule } from "./modules/business.module"; import { PresentationModule } from "./modules/presentation.module"; async function bootstrap() { // Create the container const container = new Container(); // Configure registrations (often organized into modules) container.installModule(InfrastructureModule); container.installModule(DataAccessModule); container.installModule(BusinessModule); container.installModule(PresentationModule); // Resolve the root object const app = container.resolve(Application); // Hand control to the application // From here, the container is invisible to application code await app.start(); } bootstrap().catch(console.error); // =============================================== // 2. Module Organization // =============================================== // File: src/modules/business.module.ts export const BusinessModule: ContainerModule = { register(container: Container) { // All business layer registrations in one place container.register(Lifecycle.Scoped); container.register(Lifecycle.Scoped); container.register(Lifecycle.Scoped); container.register(Lifecycle.Scoped); container.register(Lifecycle.Scoped); } }; // =============================================== // 3. Application Code - Container is Invisible // =============================================== // File: src/services/order-service.ts // ✅ CORRECT: No container reference, pure constructor injection class OrderService implements IOrderService { constructor( private readonly repository: IOrderRepository, private readonly inventory: IInventoryService, private readonly payment: IPaymentService, private readonly notifications: INotificationService, private readonly logger: ILogger ) {} async processOrder(order: Order): Promise { // Business logic only - no container.resolve() calls await this.inventory.reserve(order.items); const paymentResult = await this.payment.charge(order.total); if (paymentResult.success) { const savedOrder = await this.repository.save(order); await this.notifications.sendConfirmation(savedOrder); return OrderResult.success(savedOrder); } return OrderResult.failure(paymentResult.error); } } // ❌ WRONG: Container used as Service Locator class BadOrderService implements IOrderService { constructor(private container: IContainer) {} // Anti-pattern! async processOrder(order: Order): Promise { // Dependencies are hidden, not visible in constructor const repository = this.container.resolve(); const inventory = this.container.resolve(); // ... harder to test, harder to understand dependencies } }6d:Tc9d,// TESTING PATTERNS WITH IOC CONTAINERS // =============================================== // 1. Unit Tests - No Container Needed // =============================================== describe("OrderService", () => { it("should reserve inventory before charging payment", async () => { // Create mocks directly - no container required for unit tests const mockRepository = { save: jest.fn() }; const mockInventory = { reserve: jest.fn() }; const mockPayment = { charge: jest.fn().mockResolvedValue({ success: true }) }; const mockNotifications = { sendConfirmation: jest.fn() }; const mockLogger = { log: jest.fn() }; // Inject mocks through constructor const service = new OrderService( mockRepository as any, mockInventory as any, mockPayment as any, mockNotifications as any, mockLogger as any ); await service.processOrder(testOrder); // Assert order of operations expect(mockInventory.reserve).toHaveBeenCalledBefore(mockPayment.charge); }); }); // =============================================== // 2. Integration Tests - Test Container Configuration // =============================================== describe("OrderService Integration", () => { let container: Container; beforeEach(() => { container = new Container(); // Keep most production registrations container.installModule(BusinessModule); // Override specific services for testing container.register(); container.register(); container.register(); // Use real implementations for what we're actually testing // container.register(); // From module }); afterEach(() => { container.dispose(); }); it("should process complete order flow", async () => { const scope = container.createScope(); const service = scope.resolve(); const result = await service.processOrder(testOrder); expect(result.success).toBe(true); // Verify in-memory repository received the order const repository = scope.resolve(); expect(repository.findById(result.orderId)).toBeDefined(); }); }); // =============================================== // 3. Test Utilities - Container Factory // =============================================== function createTestContainer(overrides?: Partial) { const container = new Container(); // Base test configuration container.register(); container.register(); container.register(); // Apply all production modules container.installModule(AllProductionModules); // Apply overrides for specific tests if (overrides) { for (const [type, implementation] of Object.entries(overrides)) { container.register(type, implementation); } } return container; } // Usage in tests: const container = createTestContainer({ IPaymentService: MockPaymentService, IEmailService: NullEmailService, });44:["$","$L63",null,{"owner":"anonymous","state":{"mutations":[],"queries":[{"dehydratedAt":1792315931035,"state":{"data":{"json":{"id":"seed_107503487253abc03e9e9ef8db28da2f","slug":"ioc-containers","category":"System Design (LLD)","topic":"Inversion of Control Containers","title":"Inversion of Control Containers","description":"Master IoC containers—the architectural powerhouses that automate dependency management. Learn how containers resolve dependencies, manage object lifecycles, and enable clean architectural boundaries in enterprise applications.","difficulty":"INTERMEDIATE","estimatedMinutes":60,"pages":[{"id":"seed_d26fbcdfaec83fc587322a0df32538cf","title":"What is an IoC Container","order":0,"content":[{"id":"opening-hook","title":"The Missing Piece in Dependency Management","content":[{"data":{"content":"$64"},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand the fundamental concepts of IoC containers: what problems they solve, how they relate to DIP and dependency injection, the core services they provide (object creation, lifecycle management, dependency resolution), and why they are considered essential infrastructure in modern enterprise applications.","variant":"info"},"type":"callout"}]},{"id":"ioc-paradigm","title":"The Inversion of Control Paradigm","content":[{"data":{"content":"$65"},"type":"text"},{"data":{"rows":[["Who calls whom","Application calls library","Framework calls application code"],["Object creation","Application creates objects explicitly","Framework creates objects on demand"],["Lifecycle management","Application tracks object lifetimes","Framework manages lifecycles"],["Configuration","Hardcoded in application","External, declarative configuration"],["Flow control","Application determines execution order","Framework orchestrates execution"],["Extension mechanism","Modify existing code","Implement interfaces, register callbacks"]],"caption":"Traditional Control vs Inversion of Control","headers":["Aspect","Traditional Control","Inversion of Control"]},"type":"table"},{"data":{"icon":"Lightbulb","title":"The Hollywood Principle","content":"IoC is often summarized as the 'Hollywood Principle': Don't call us, we'll call you. Just as aspiring actors don't pester casting directors but wait to be contacted, application components don't actively seek dependencies but wait for the framework to provide them. This passive posture is key to achieving loose coupling.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"ioc-to-containers","title":"From IoC to IoC Containers","content":[{"data":{"content":"$66"},"type":"text"},{"data":{"fileName":"IoC Container Conceptual Model","languages":[{"code":"$67","label":"TypeScript","value":"typescript"},{"code":"$68","label":"C#","value":"csharp"},{"code":"$69","label":"Java","value":"java"}]},"type":"code"},{"data":{"content":"**The Key Insight:**\n\nWithout a container, dependency injection still requires someone to manually construct objects and wire them together. In a trivial application, this is manageable. In an enterprise application with hundreds of classes, manual wiring becomes a significant portion of the codebase—error-prone, hard to maintain, and scattered across multiple locations.\n\nThe container centralizes this responsibility. Registration happens in one place (or is automated through conventions). Resolution happens automatically. The container becomes the single source of truth for how objects are created and connected."},"type":"text"}],"titleType":"number","titleNumber":2},{"id":"problem-ioc-solves","title":"The Problem IoC Containers Solve","content":[{"data":{"content":"To appreciate IoC containers fully, let's examine what application composition looks like without one. Consider a moderately complex business application with layered architecture."},"type":"text"},{"data":{"left":[{"data":{"items":["Every dependency must be explicitly created","Creation order must be manually managed","Lifecycle management is ad-hoc","Changes ripple through composition code","Testing requires rebuilding object graphs","Configuration is scattered across files","Singleton management requires extra patterns"],"title":{"icon":"XCircle","text":"Manual Wiring Without Container","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["Container creates objects on demand","Dependency graph resolved automatically","Lifecycle policies declared, not coded","Adding dependency = one registration","Test configuration swaps implementations","Configuration centralized and declarative","Singletons are a lifecycle option"],"title":{"icon":"CheckCircle","text":"With IoC Container","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"fileName":"manual-wiring-problem.ts","languages":[{"code":"$6a","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"icon":"AlertCircle","title":"The Maintenance Burden","content":"This example shows ~25 objects being manually wired. Real enterprise applications often have hundreds. Every new service means updating this composition code. Every refactored dependency ripples through it. The composition root becomes a bottleneck for development velocity and a source of merge conflicts.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"core-container-services","title":"Core Services of an IoC Container","content":[{"data":{"content":"Every IoC container, regardless of language or framework, provides a core set of services. Understanding these services is essential for effective container usage."},"type":"text"},{"data":{"items":["**Type Registration** — The mechanism by which you tell the container 'when someone needs this interface, give them this implementation.' Registration creates the mapping between abstractions and concretions.","**Dependency Resolution** — When you request a type, the container constructs it and all its dependencies recursively. This is automatic graph traversal—if A needs B and B needs C, requesting A creates C, then B, then A.","**Lifecycle Management** — Different objects need different lifetimes. Some should be singletons (one instance forever). Some should be scoped (one instance per request). Some should be transient (new instance every time). The container manages this.","**Configuration Binding** — Modern containers can bind configuration values (from files, environment, etc.) to objects, separating configuration from code entirely.","**Interception/AOP** — Advanced containers support aspect-oriented programming, allowing you to wrap resolved objects with cross-cutting concerns like logging, caching, or transaction management."],"title":{"icon":"Target","text":"Core Container Services","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"content":"**Service 1: Type Registration**\n\nRegistration tells the container about your types. There are several registration patterns:\n\n- **Explicit Registration** — You manually register each type mapping\n- **Convention-Based Registration** — Types are auto-registered based on naming conventions (e.g., `IFoo` maps to `Foo`)\n- **Assembly Scanning** — The container scans assemblies for types implementing certain interfaces\n- **Attribute-Based Registration** — Decorators/attributes on classes indicate registration\n\nThe choice of registration pattern affects development velocity and explicitness tradeoffs."},"type":"text"},{"data":{"fileName":"registration-patterns.ts","languages":[{"code":"// REGISTRATION PATTERNS ILLUSTRATED\n\n// 1. EXPLICIT REGISTRATION - Most control, most verbose\ncontainer.register();\ncontainer.register();\ncontainer.register();\n// ... repeat for every type\n\n// 2. CONVENTION-BASED REGISTRATION - Less verbose, requires naming discipline\ncontainer.registerByConvention({\n // All classes implementing interfaces matching \"I{Name}\" → \"{Name}\"\n pattern: /^I(.+)$/,\n in: \"./src/repositories\",\n});\n\n// 3. ASSEMBLY/MODULE SCANNING - Automatic, requires marker interfaces\ncontainer.scan(\"./src/**/*.ts\", {\n includeInterfaces: [IRepository, IService],\n lifecycle: Lifecycle.Scoped,\n});\n\n// 4. ATTRIBUTE/DECORATOR-BASED - Self-documenting, tight coupling to container\n@Injectable({ lifecycle: \"singleton\" })\nclass ConsoleLogger implements ILogger {\n log(message: string) { console.log(message); }\n}\n\n// The container finds all @Injectable classes automatically","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"content":"**Service 2: Dependency Resolution**\n\nResolution is where the magic happens. When you request a type, the container:\n\n1. Looks up the registration for that type\n2. Examines the constructor to find required dependencies\n3. Recursively resolves each dependency\n4. Creates instances according to lifecycle rules\n5. Injects dependencies and returns the fully-constructed object\n\nThis process is transparent to your application code. You ask for `IUserService`; you get a fully-wired `UserService` with all its dependencies satisfied."},"type":"text"},{"data":{"height":"450px","mermaidSyntax":"flowchart TB\n subgraph Request[\"Resolution Request\"]\n A[\"Resolve IUserService\"]\n end\n\n subgraph Container[\"Container Resolution\"]\n B[\"Check Registration\"] --> C[\"Examine Constructor\"]\n C --> D[\"Find Dependencies:\n- IUserRepository\n- ILogger\n- ICache\"]\n D --> E[\"Resolve IUserRepository\"]\n D --> F[\"Resolve ILogger\"]\n D --> G[\"Resolve ICache\"]\n E --> H[\"Create PostgresUserRepository\"]\n F --> I[\"Reuse Singleton Logger\"]\n G --> J[\"Create RedisCache\"]\n end\n\n subgraph Assembly[\"Object Assembly\"]\n H --> K[\"new UserService(\n userRepository,\n logger,\n cache\n)\"]\n I --> K\n J --> K\n K --> L[\"Return UserService\"]\n end\n\n A --> B\n L --> M[\"Application receives\nfully-wired service\"]\n"},"type":"mermaid-excalidraw"}],"titleType":"number","titleNumber":4},{"id":"lifecycle-management","title":"Lifecycle Management In Depth","content":[{"data":{"content":"Object lifecycle is one of the most critical services an IoC container provides. Different objects have different lifetime requirements, and mixing these incorrectly is a common source of subtle bugs.\n\n**The Three Standard Lifecycles:**"},"type":"text"},{"data":{"rows":[["**Singleton**","Single Instance","One instance for entire application lifetime","Loggers, configuration, connection pools, caches"],["**Scoped**","Per-Request, Per-Session","One instance per scope (e.g., HTTP request)","Database contexts, user session data, unit of work"],["**Transient**","Per-Resolution, Per-Dependency","New instance every time resolved","Stateless services, validators, factories"]],"caption":"Standard Object Lifecycles","headers":["Lifecycle","Also Known As","Behavior","Use Cases"]},"type":"table"},{"data":{"icon":"AlertCircle","title":"The Captive Dependency Problem","content":"A singleton that takes a scoped dependency captures a reference that outlives its intended lifetime. The first request creates the scoped dependency; all subsequent requests reuse that stale instance. This is called the 'captive dependency' problem and is a common IoC container pitfall. Most containers detect and warn about this misconfiguration.","variant":"warning"},"type":"callout"},{"data":{"fileName":"lifecycle-examples.ts","languages":[{"code":"$6b","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"content":"**Scope Hierarchies:**\n\nScopes often form hierarchies. An HTTP request scope might be a child of an application scope. A background job might create its own scope. Understanding scope hierarchy is crucial for proper lifecycle management.\n\n**Disposal and Cleanup:**\n\nContainers track disposable objects and dispose them when their scope ends. A scoped `DbContext` is automatically disposed when the request completes. This automatic resource management prevents resource leaks that manual composition often introduces."},"type":"text"}],"titleType":"number","titleNumber":5},{"id":"composition-root","title":"The Composition Root","content":[{"data":{"content":"A critical architectural concept when using IoC containers is the **Composition Root**—the single location in an application where the container is configured and where the object graph is first resolved.\n\n**Definition:**\n\nThe Composition Root is the application's entry point for dependency injection. It's where you:\n\n1. Create the container\n2. Configure all registrations\n3. Resolve the root object(s) of the application\n4. Hand control to the resolved objects\n\nAfter the Composition Root, no application code should reference the container directly. The container is infrastructure, not a service locator to be passed around."},"type":"text"},{"data":{"icon":"Lightbulb","title":"Container as Infrastructure, Not Service Locator","content":"A common anti-pattern is injecting the container itself into classes and calling container.resolve() throughout the application. This is the Service Locator pattern—an anti-pattern that hides dependencies, makes code harder to test, and defeats the purpose of dependency injection. The container should be invisible after the Composition Root.","variant":"tip"},"type":"callout"},{"data":{"fileName":"composition-root.ts","languages":[{"code":"$6c","label":"TypeScript","value":"typescript"}]},"type":"code"}],"titleType":"number","titleNumber":6},{"id":"containers-and-testability","title":"IoC Containers and Testability","content":[{"data":{"content":"One of the most significant benefits of IoC containers is the testability they enable. By centralizing dependency configuration, you can easily swap implementations for testing without changing application code."},"type":"text"},{"data":{"items":["**Unit Testing** — Classes receive dependencies through constructors, making it trivial to provide mock implementations without container involvement","**Integration Testing** — Create a test container configuration that swaps only specific services (e.g., in-memory database instead of PostgreSQL)","**Environment-Based Configuration** — Container configuration can vary by environment—production, staging, test—allowing environment-appropriate implementations","**Stub Implementations** — Register stub implementations for external services (payment gateways, email) during testing","**Scope Isolation** — Each test can have its own container scope, ensuring tests don't leak state to each other"],"title":{"icon":"CheckCircle","text":"Testing Benefits of IoC Containers","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"fileName":"testing-with-ioc.ts","languages":[{"code":"$6d","label":"TypeScript","value":"typescript"}]},"type":"code"}],"titleType":"number","titleNumber":7},{"id":"when-to-use-containers","title":"When to Use IoC Containers","content":[{"data":{"content":"IoC containers are powerful tools, but they're not universally appropriate. Understanding when they add value—and when they add unnecessary complexity—is a mark of engineering maturity."},"type":"text"},{"data":{"left":[{"data":{"items":["Application has many interdependent services","Different environments need different implementations","Testability is a priority","Object lifecycle management is complex","Team is familiar with DI principles","Framework already includes container support","Application will grow and evolve significantly"],"title":{"icon":"CheckCircle","text":"Use IoC Containers When","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["Application is small and unlikely to grow","Dependency graph is simple (few services)","Team is unfamiliar with DI concepts","Adding a container would be the only reason to add a framework dependency","Performance-critical code paths can't afford reflection overhead","Scripting or utility applications"],"title":{"icon":"XCircle","text":"Consider Alternatives When","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"icon":"Info","title":"The Alternative: Pure DI","content":"For applications that don't warrant a full container, 'Pure DI' (also called 'Poor Man's DI') uses constructor injection without any container. You manually wire objects in a composition root. This is simpler, has no framework dependency, but scales poorly. For applications with 10-20 services, Pure DI is often sufficient. Beyond that, containers earn their keep.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":8},{"id":"summary","title":"Summary: The Role of IoC Containers","content":[{"data":{"content":"We've covered fundamental ground in understanding what IoC containers are and why they matter. Let's consolidate these insights:"},"type":"text"},{"data":{"type":"ordered","items":["**IoC inverts control flow** — Frameworks call your code; your code doesn't call frameworks. This enables loose coupling and flexible architectures.","**IoC containers automate dependency injection** — They create objects, resolve dependencies recursively, and manage lifecycles without manual wiring code.","**Containers provide core services** — Type registration, dependency resolution, lifecycle management, and often configuration binding and AOP support.","**Lifecycle management prevents resource leaks** — Singleton, scoped, and transient lifecycles ensure objects live exactly as long as needed.","**The Composition Root centralizes configuration** — One location where the container is configured; after that, it's invisible to application code.","**Containers enable testability** — Easy swapping of implementations for testing without changing business logic.","**Not always necessary** — Simple applications may use Pure DI; containers add value as complexity grows."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's Next:**\n\nNow that we understand what IoC containers are and the services they provide, the next page will dive into **container configuration**—the various approaches to registering types, organizing registrations into modules, and handling complex registration scenarios like open generics, decorators, and conditional registration."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand the fundamental concepts of IoC containers: the inversion of control paradigm, how containers automate dependency injection, core container services, lifecycle management, the composition root pattern, and testability benefits. Next, we'll explore how to configure containers effectively.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":9}],"isLocked":false},{"id":"seed_556dee11f5f79b338d249485306225bc","title":"Container Configuration","order":1,"content":null,"isLocked":true},{"id":"seed_0c9de4732db41b4dba3e02bdbf41f5ff","title":"Automatic Dependency Resolution","order":2,"content":null,"isLocked":true},{"id":"seed_112c146417c6c7a27ebcf6cdad991b3a","title":"Popular Frameworks Overview","order":3,"content":null,"isLocked":true}]}},"dataUpdateCount":1,"dataUpdatedAt":1792315931027,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["learningContent","getModule"],{"input":{"slug":"ioc-containers"},"type":"query"}],"queryHash":"[[\"learningContent\",\"getModule\"],{\"input\":{\"slug\":\"ioc-containers\"},\"type\":\"query\"}]"},{"dehydratedAt":1792315931036,"state":{"data":{"json":null},"dataUpdateCount":1,"dataUpdatedAt":1792315931033,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["learningContent","getProgress"],{"input":{"moduleId":"seed_107503487253abc03e9e9ef8db28da2f"},"type":"query"}],"queryHash":"[[\"learningContent\",\"getProgress\"],{\"input\":{\"moduleId\":\"seed_107503487253abc03e9e9ef8db28da2f\"},\"type\":\"query\"}]"},{"dehydratedAt":1792315931036,"state":{"data":{"json":null},"dataUpdateCount":1,"dataUpdatedAt":1792315931034,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["feedback","get"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_556dee11f5f79b338d249485306225bc"},"type":"query"}],"queryHash":"[[\"feedback\",\"get\"],{\"input\":{\"contentId\":\"seed_556dee11f5f79b338d249485306225bc\",\"contentType\":\"LEARNING_PAGE\"},\"type\":\"query\"}]"},{"dehydratedAt":1792315931036,"state":{"data":{"json":null},"dataUpdateCount":1,"dataUpdatedAt":1792315931034,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["feedback","getUserLike"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_556dee11f5f79b338d249485306225bc"},"type":"query"}],"queryHash":"[[\"feedback\",\"getUserLike\"],{\"input\":{\"contentId\":\"seed_556dee11f5f79b338d249485306225bc\",\"contentType\":\"LEARNING_PAGE\"},\"type\":\"query\"}]"},{"dehydratedAt":1792315931036,"state":{"data":{"json":[]},"dataUpdateCount":1,"dataUpdatedAt":1792315931034,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["highlights","getHighlights"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_556dee11f5f79b338d249485306225bc"},"type":"query"}],"queryHash":"[[\"highlights\",\"getHighlights\"],{\"input\":{\"contentId\":\"seed_556dee11f5f79b338d249485306225bc\",\"contentType\":\"LEARNING_PAGE\"},\"type\":\"query\"}]"},{"dehydratedAt":1792315931036,"state":{"data":"$undefined","dataUpdateCount":0,"dataUpdatedAt":0,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"pending","fetchStatus":"fetching"},"queryKey":[["highlights","getPopularHighlights"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_556dee11f5f79b338d249485306225bc","minCount":2},"type":"query"}],"queryHash":"[[\"highlights\",\"getPopularHighlights\"],{\"input\":{\"contentId\":\"seed_556dee11f5f79b338d249485306225bc\",\"contentType\":\"LEARNING_PAGE\",\"minCount\":2},\"type\":\"query\"}]","promise":"$@6e"}]},"children":"$L6f"}]