Ogni applicazione .NET inizia con un controller pulito e due dipendenze. Poi la realtà colpisce: dieci servizi iniettati, tutti istanziati a ogni request - che vengano usati o no. Questa sessione seziona il costo nascosto della constructor injection sotto carico e mostra come due strumenti lo eliminano senza toccare la business logic.
Iniziamo con Lazy< T > e DryIoc: come posticipare la costruzione degli oggetti al momento esatto in cui servono, come gestire i riferimenti circolari in modo elegante, e come misurare l'impatto con Microsoft Aspire (spoiler: riduzione di 4–5× nei tempi di costruzione DI, nelle allocazioni heap e nella pressione sul GC - su endpoint reali di produzione).
Poi passiamo al secondo nemico: le operazioni lente per natura - stampa massiva, invio bulk di email, generazione di report pesanti. Analizziamo un PrintSpooler reale costruito con Hangfire: job fire-and-forget, distributed lock per evitare race condition, polling del progresso dal frontend, serializzazione dell'identità fuori dalla pipeline HTTP, e la riga che non si deve mai togliere (throw) se si vuole che i retry scattino davvero.
Alla fine avrai un playbook concreto per fermare lo spinner - e tenere l'utente vivo.

I code sample provengono da un'applicazione .NET 10 / ASP.NET Core in produzione.
I benchmark sono stati misurati con Microsoft Aspire Dashboard su 500 request reali consecutive. Argomenti trattati: Lazy< T >, DryIoc, Microsoft.Extensions.DependencyInjection, Hangfire (fire-and-forget, scheduled, recurring job), distributed cache, polling pattern.