Factory patterns in .NET codebases promise control over object creation but often create an illusion of it — centralizing coupling rather than eliminating it. The post traces the evolution from manual factories to ASP.NET Core's DI container, arguing that the container distributes responsibility more effectively than traditional factories. It distinguishes harmful abstractions (over-engineered factory hierarchies) from useful ones (IHttpClientFactory hiding socket pooling complexity). The core argument: factories are valid when runtime data drives creation or construction is complex, but should not be added preemptively. Clarity comes from well-distributed responsibilities, not centralized control.
Table of contents
The Desire to Control CreationThe Rise of Factories in .NET CodebasesWhen Control Becomes CouplingThe Illusion of FlexibilityASP.NET Core and the Container as the Ultimate FactoryA Useful Illusion: IHttpClientFactoryThe Trap of Over-EngineeringWhen Factories Still Make SenseFrom Control to ClaritySort: