What is *Dependency Injection in .NET* by Mark Seemann about?

*Dependency Injection in .NET* is a practical guide to implementing dependency injection (DI) in .NET applications. It explains how DI reduces tight coupling between components using patterns like Constructor Injection and integrates with frameworks like ASP.NET MVC. The book also covers DI containers (e.g., StructureMap, Castle Windsor) and anti-patterns to avoid, helping developers build maintainable, testable code.

Who should read *Dependency Injection in .NET*?

This book is ideal for C# developers seeking to master DI principles, whether they’re new to DI or experienced. It’s particularly valuable for engineers working with .NET frameworks like ASP.NET MVC or transitioning to DI-enabled architectures. Technical leads and architects will also benefit from its coverage of object lifetime management and DI refactorings.

Is *Dependency Injection in .NET* worth reading?

Yes—the book won the 2013 Jolt Award for Productivity and remains a definitive resource. It balances theory with hands-on C# examples, critiques common pitfalls (e.g., Service Locator anti-pattern), and demonstrates integration with both Microsoft and open-source DI tools. Developers praise its clear explanations of advanced topics like interception and composition roots.

What are the key DI frameworks covered in *Dependency Injection in .NET*?

Mark Seemann details six major frameworks: **StructureMap**, **Castle Windsor**, **Unity**, **Spring.NET**, **Autofac**, and **MEF**. The book compares their configuration approaches, lifetime management, and interception capabilities, helping readers choose the right tool for projects ranging from legacy apps to modern microservices.

How does *Dependency Injection in .NET* address anti-patterns?

The book dedicates a section to DI anti-patterns like *Control Freak* (overusing `new` operators) and *Bastard Injection* (mixing default and injected dependencies). It provides refactoring strategies, advocating for explicit composition roots and constructor injection to avoid hidden dependencies and improve testability.

What is the "Composition Root" concept in the book?

A **Composition Root** is the single location where an application’s object graph is assembled. Seemann emphasizes centralizing dependency configuration here rather than scattering it across components. This pattern simplifies maintenance, ensures consistent lifetime management, and reduces coupling between modules.

How does *Dependency Injection in .NET* relate to .NET Core’s built-in DI?

While the book predates .NET Core, its principles apply directly to Microsoft’s built-in `IServiceProvider`. Concepts like lifetime scopes (transient vs. singleton) and interface-based design align with .NET Core’s DI implementation. The book’s framework-agnostic patterns help developers adapt to newer versions like .NET 7/8.

What real-world applications does the book’s "Comprehensive Example" demonstrate?

The example illustrates DI in a full-stack .NET app, covering database integration, service layer decoupling, and UI-layer dependency management. It shows how DI enables easier testing, modular replacements (e.g., swapping mock repositories), and scalable architecture decisions.

Riassunto di Dependency injection in .NET

Mark Seemann

4.43(777 Reviews)

Panoramica del Riassunto di Dependency injection in .NET

Rivoluziona il tuo codice C# con "Dependency Injection in .NET" - la guida fondamentale di Mark Seemann che ha trasformato il modo in cui gli sviluppatori approcciano i principi SOLID. Il libro che ha reso il disaccoppiamento (loose coupling) di tendenza prima ancora che i microservizi diventassero mainstream.

Scegli come raccontarlo

Esplora il Riassunto di Dependency injection in .NET con diversi stili di apprendimento

Le stesse idee di Dependency injection in .NET. Scegli la voce, la profondità e il ritmo adatti a te. Cambia in qualsiasi momento.

Capitolo 1

Il frigorifero nella vostra cucina

Partiamo con un'affermazione strana: il concetto più importante nell'architettura del software professionale è lo stesso identico motivo per cui il vostro frigorifero ha una spina invece di un cavo saldato direttamente nel muro. Mark Seemann ha passato anni a osservare gli sviluppatori scrivere codice. Codice che funzionava benissimo il giorno della consegna, ma che diventava quasi impossibile da toccare poco tempo dopo. E non perché la logica fosse sbagliata. Il problema era che tutto era collegato direttamente a tutto il resto. Esattamente come si costruivano le case di una volta, con il cavo del frigorifero giuntato direttamente dentro la parete. Volete un frigorifero nuovo? Dovete chiamare un elettricista. Volete spostarlo? Dovete spaccare il cartongesso. Poi qualcuno ha inventato la presa elettrica. Alla parete non importa di che marca sia il vostro frigorifero. Offre una presa standard, una forma fissa, una promessa. Qualsiasi elettrodomestico che rispetti quella forma può essere collegato lì. Il frigorifero non sa e non si cura di come venga generata l'elettricità: che arrivi da una centrale a carbone, da pannelli solari o da un generatore diesel in cantina, a lui non interessa. Sa solo che riceverà energia attraverso quella presa. Questa, in sostanza, è la Dependency Injection. Non è uno strumento. Non è una libreria da installare. È una scelta d'architettura: costruire il software in modo che i componenti che svolgono il lavoro vero non debbano mai andare a prendersi da soli ciò da cui dipendono. Al contrario, le dipendenze vengono consegnate loro dall'esterno, attraverso una presa standard. Il libro di Seemann, che ha vinto il Premio Jolt ed è diventato uno dei testi di riferimento sull'argomento, sostiene una tesi chiara: questa singola abitudine, se applicata con costanza, è ciò che separa il codice che si può continuare a modificare dal codice che si pietrifica. Ed ecco perché la cosa va ben oltre i soliti paroloni tecnici. Seemann dice chiaramente che la Dependency Injection viene fraintesa di continuo. C'è chi pensa sia solo un modo elegante per fare late binding. Non è così. C'è chi crede che serva soltanto per le unit test. Aiuta, certo, ma è un effetto secondario, non il fine principale. Molti pensano che sia indispensabile usare un container di Dependency Injection, cioè un framework intelligente che colleghi gli oggetti in automatico. Ma non serve per forza. Si può fare tutto a mano, in quella che lui chiama DI pura, e tantissimi sistemi professionali fanno esattamente questo. E infine la si confonde spesso con il pattern Service Locator, che a prima vista sembra simile ma che, come vedremo, è in realtà l'esatto contrario di questa disciplina. Nelle prossime righe vedremo come funziona davvero. Non ci limiteremo a dire che un accoppiamento debole è cosa buona. Vedremo come prendere un'applicazione aggrovigliata e saldata male e rovesciarla da cima a fondo, per far sì che sia tenuta insieme da prese e non da saldature. Vedremo come prendere il controllo del ciclo di vita degli oggetti — quanto vivono e quando muoiono — trasformandolo in una scelta consapevole invece che in un incidente. E vedremo come agganciare al codice di business cose come log, controlli di sicurezza e logiche di reintroduzione, senza che quel codice sappia mai della loro esistenza. Ripartiamo da dove parte Seemann: dal tipo specifico di dipendenza che merita davvero questo trattamento.

Capitolo 2

Le dipendenze di cui preoccuparsi davvero

Non tutte le dipendenze presenti nel software sono un problema. Questa è la prima cosa da chiarire. È facile cadere nella tentazione di pensare che Dependency Injection significhi avvolgere qualunque cosa in un'interfaccia per poi iniettarla, ma sarebbe un lavoro estenuante e del tutto inutile. Seemann traccia una linea netta tra quelle che chiama dipendenze stabili e dipendenze volatili. Una dipendenza stabile è, ad esempio, una classe della libreria di classi base di .NET, una stringa, una lista, un'operazione aritmetica di base. È deterministica. Si comporta sempre allo stesso modo, ogni singola volta. Non sparirà e non la sostituirete mai con qualcos'altro. Non c'è alcun motivo di iniettare una stringa. Una dipendenza volatile è completamente diversa. È volatile se richiede un ambiente preparato attorno a sé, come una connessione al database, una chiamata di rete o l'accesso al file system. È volatile se non esiste ancora, magari perché state scrivendo del codice oggi per una parte di sistema che un altro team sta ancora costruendo. Ed è volatile se si comporta in modo non deterministico, restituendo risposte diverse a seconda dell'ora del giorno, dello stato di un sistema esterno, di numeri casuali o della data corrente. Database, servizi web, l'orologio di sistema, generatori di numeri casuali: queste sono le parti del codice che secondo Seemann meritano di essere astratte dietro un'interfaccia e ricevute dall'esterno, invece di essere istanziate direttamente ovunque servano. Questa distinzione è fondamentale perché vi dice dove concentrare gli sforzi. Non serve fare il teatrino della Dependency Injection ovunque. Serve esattamente sui punti di giunzione, nei luoghi in cui l'applicazione tocca il mondo esterno, che è imprevedibile. Per rendere l'idea concreta, Seemann racconta una storia completa. Una sviluppatrice di nome Mary Rowan sta creando un'applicazione e-commerce: ASP.NET Core per la parte web, Entity Framework Core per parlare con il database, e una logica per calcolare sconti e mettere in evidenza certi prodotti in home page. La prima versione di questa app — che Seemann scrive volutamente male — mostra chiaramente cosa succede quando si ignora del tutto la differenza tra dipendenze stabili e volatili. Un collega di nome Jens spinge la classe di logica di dominio di Mary, ProductService, verso quella che sembra la strada più ovvia e pragmatica: accedere direttamente al contesto del database di Entity Framework, cioè CommerceContext, da dentro la logica aziendale. Basta istanziarlo lì con un bel `new`. Perché complicarsi la vita? Funziona, compila, va in produzione. Solo che adesso ProductService è saldato a Entity Framework. Seemann mostra cosa succede quando si prova a testare questa classe, o a cambiare il livello di accesso ai dati, o a lavorare sull'interfaccia utente mentre qualcun altro modifica lo schema del database. Non si può fare. Se disegnaste il grafico delle dipendenze con delle frecce, vedreste l'interfaccia utente dipendere dal dominio, e il dominio dipendere direttamente dal livello dati concreto. Se cambiate l'interfaccia utente non succede nulla, a nessuno importa. Ma se provate a cambiare il livello dati, il blocco risale dritto attraverso la logica di business fino al controller. Una modifica in fondo alla catena vi costringe a riscrivere la parte in cima. La diagnosi di Seemann è chirurgica: il punto non è che Entity Framework sia fatto male, ma che ProductService — un pezzo di logica aziendale che dovrebbe essere stabile e astratto — ha preso una dipendenza rigida da qualcosa di volatile. La soluzione non è una pezza. È l'inversione.

Vedi ogni parola mentre la ascolti

Segui la lettura senza sforzo mentre ogni parola del Riassunto di Dependency injection in .NET si illumina in tempo reale.

Capitolo 3

Capovolgere i collegamenti

Ed ecco il meccanismo concreto, quello che spesso viene solo accennato senza mai essere mostrato: come si prende quel groviglio accoppiato e lo si capovolge? La mossa si chiama Principio di inversione delle dipendenze, e una volta capita sembra quasi un gioco di prestigio. Invece di far dipendere ProductService dalla classe concreta di accesso ai dati, si definisce un'interfaccia, IProductRepository, che risiede all'interno dello stesso livello di dominio, proprio accanto a ProductService. Non dentro il livello dati. Dentro il dominio. Questa è la parte che molti saltano, ma è tutto qui il trucco. Il livello di dominio definisce la forma di ciò di cui ha bisogno, secondo i propri termini, ed è il livello dati a doversi adeguare e a dover implementare quella forma. Pensate a cosa succede alle frecce nel diagramma delle dipendenze. Prima il dominio dipendeva dai dati. Ora i dati dipendono dal dominio, perché SqlProductRepository, che sta nel livello di accesso ai dati, implementa IProductRepository, un'interfaccia di proprietà del dominio. La direzione della dipendenza si è invertita nei fatti, anche se il flusso delle chiamate ai metodi durante l'esecuzione non è cambiato di una virgola. ProductService chiede ancora i prodotti e li riceve. Ma sulla carta, in termini di chi dipende da chi, adesso il dominio possiede solo astrazioni, e tutto ciò che è volatile — il database, il framework web — punta verso l'interno, non viceversa. Seemann ricostruisce l'intera applicazione di Mary in questo modo, lavorando dall'esterno verso l'interno. Il controller dipende solo da IProductService. ProductService viene costruito passando IProductRepository e IUserContext al suo costruttore, senza che la classe vada a prenderseli da sola. La classe concreta SqlProductRepository, che tocca effettivamente CommerceContext ed Entity Framework, vive interamente nel livello dati e implementa l'interfaccia definita dal dominio. C'è anche un adattatore, AspNetUserContextAdapter, che prende le informazioni sull'identità dell'utente di ASP.NET e le traduce nella forma che IUserContext si aspetta, così il dominio non deve nemmeno sapere che ASP.NET esista. Se ridisegnate il grafico delle dipendenze dopo questo refactoring, notate una cosa straordinaria: il livello di dominio ha zero dipendenze verso l'esterno. Nessuna. Siede al centro, pura logica di business, e sia l'interfaccia utente sia il livello dati puntano verso di lui, implementando le sue interfacce, mai il contrario. Ora potete sostituire Entity Framework con una tecnologia di database del tutto diversa e ProductService non se ne accorgerà nemmeno, non cambierà e non dovrà essere ricompilato. Questo è ciò che significa davvero componibilità. A questo punto sorge una domanda spontanea, ed è la stessa che Seemann affronta a viso aperto. Se ProductService chiede semplicemente un IProductRepository nel suo costruttore e non ne crea mai uno da solo, qualcuno, da qualche parte, dovrà pur creare il vero SqlProductRepository e glielo dovrà consegnare. Chi se ne occupa? È qui che l'intera disciplina regge o crolla.

Capitolo 4

L'unico posto in cui è permesso usare "new"

La risposta è un punto unico e ben preciso dell'applicazione chiamato Composition Root. Seemann lo descrive come un unico luogo logico, il più vicino possibile al punto d'ingresso dell'applicazione, in cui viene costruito l'intero grafo degli oggetti. Ogni dipendenza volatile viene istanziata qui e passata agli oggetti che ne hanno bisogno. Ovunque altro nel codice, la regola è assoluta: nessun oggetto volatile viene creato con un semplice `new` al di fuori di questo punto. All'inizio questo può sembrare impossibile. Se ProductService ha bisogno di un repository, il repository ha bisogno di una stringa di connessione, e la stringa di connessione ha bisogno di configurazione, non significa che la Composition Root finirà per dover conoscere ogni singolo dettaglio dell'intero sistema? Seemann la chiama una "esplosione di dipendenze apparente", e spiega con cura perché si tratta di un'illusione. Non è che la Composition Root debba improvvisamente capire decine di concetti slegati tra loro. È una questione di transitività. Se A dipende da B, e B dipende da C, qualcuno, da qualche parte, deve pur fornire C per poter costruire A. Questo è sempre stato vero. La Composition Root si limita a renderlo visibile invece di nasconderlo in decine di parole chiave `new` sparse in decine di costruttori diversi. Come si presenta all'atto pratico? Immaginate la versione applicazione console di Mary, un piccolo strumento per aggiornare le valute. Il punto d'ingresso del programma, il metodo Main, è la Composition Root. Per prima cosa carica la configurazione: la stringa di connessione, una chiave API, qualunque cosa richieda il mondo esterno. Poi, e solo allora, inizia a costruire. Crea prima i pezzi volatili di livello più basso, ad esempio un parser di valute collegato al database, poi li avvolge negli oggetti del livello superiore, continuando a passare le istanze verso l'alto finché non ha un grafo di oggetti completo e pronto all'uso. A quel punto chiama un solo metodo per avviare tutto. Niente di questo schema si affida a un framework. Sono solo costruttori, chiamati nell'ordine giusto, in un solo file, nell'unico momento in cui l'applicazione si avvia. Tutto qui. È questo che si intende quando si parla di DI pura. Nessuna magia, nessuna reflection, nessun container. Soltanto una costruzione centralizzata e consapevole degli oggetti, tenuta ben lontana dalla logica aziendale. La versione per ASP.NET Core funziona sullo stesso principio, ma si aggancia a un punto di estensione specifico chiamato IControllerActivator, che il framework chiama ogni volta che deve creare un controller per gestire una richiesta in arrivo. La classe CommerceControllerActivator di Mary implementa quell'interfaccia e, al suo interno, costruisce l'intero grafo: il repository, l'adattatore del contesto utente, il servizio, e restituisce al framework il controller pronto. Stessa idea del metodo Main dell'app console, solo eseguita a ogni richiesta invece che una volta sola all'avvio.

Ottieni di più dal Riassunto di Dependency injection in .NET

Ricevi spunti ogni giorno da oltre 100.000 lezioni
Le parole si illuminano in sincronia con l'audio
La tua libreria salvata su ogni dispositivo

Capitolo 5

Iniezione nel costruttore e le trappole apparentemente simili

Una volta stabilito che la Composition Root è l'unico posto autorizzato a creare gli oggetti, la domanda successiva è: in che modo i singoli componenti chiedono ciò di cui hanno bisogno? La risposta di Seemann è che esiste un pattern predefinito e caldamente raccomandato, da usare quasi sempre: l'Iniezione nel costruttore. Una classe che ha bisogno di una dipendenza volatile la dichiara come parametro nel proprio costruttore. Tutto qui. Il costruttore di ProductService accetta un IProductRepository e un IUserContext. Una volta dentro la classe, quelle dipendenze esistono già, pronte all'uso, e la classe non deve mai preoccuparsi di dove arrivino. La regola di Seemann è rigida: una classe dovrebbe avere un unico costruttore, e ogni dipendenza di cui ha davvero bisogno deve figurare lì, senza essere opzionale. Esiste anche l'Iniezione di metodo, riservata ai casi in cui una dipendenza varia a ogni singola chiamata anziché rimanere fissa per tutta la vita dell'oggetto, e l'Iniezione di proprietà, usata raramente per dipendenze opzionali in librerie riutilizzabili, dove esiste un comportamento predefinito sensato se nessuno fornisce altro. Ma l'Iniezione nel costruttore resta la scelta principale e più sicura, perché rende i requisiti di una classe del tutto visibili e impossibili da dimenticare. Non è letteralmente possibile costruire l'oggetto senza fornirgli ciò di cui ha bisogno. Capire dove questo meccanismo si inceppa è molto utile, e Seemann dedica del tempo a spiegare questi errori perché sono trappole molto allettanti. Il primo errore è quello che chiama Control Freak: ogni volta che una dipendenza volatile viene creata con `new` fuori dalla Composition Root. È il primo errore commesso da Mary, ripresentato con abiti diversi. Magari non è il costruttore a farlo, magari è un metodo factory, o un helper statico. Non importa. Nel momento in cui una classe crea da sola la propria dipendenza volatile invece di riceverla, quella classe si salda a un'implementazione specifica. E tutti i benefici — testabilità, sostituibilità, sviluppo in parallelo — svaniscono all'istante. La seconda trappola è più sottile e persino più pericolosa, perché sembra una scelta responsabile: il Service Locator. Invece di istanziare direttamente una dipendenza, la classe tiene un riferimento a un oggetto container generico e gli chiede, a runtime: "dammi un IProductRepository". Sembra Dependency Injection. C'è un'interfaccia, c'è flessibilità. Ma guardando meglio, la dipendenza della classe verso quel repository è nascosta dentro i metodi, invece di essere dichiarata chiaramente nel costruttore. Chiunque guardi la firma del costruttore non può sapere di cosa abbia davvero bisogno la classe per funzionare. Scrivere i test diventa più difficile, perché bisogna configurare un intero locator con tutto ciò che la classe potrebbe chiedere, compresi elementi che non servono per quel test specifico. Seemann dice chiaramente che è facile cadere in questo errore perché il pattern è utile in un solo punto: dentro l'infrastruttura di un container di Dependency Injection, al limite della Composition Root. L'anti-pattern consiste nell'usarlo al posto dell'Iniezione nel costruttore nel normale codice dell'applicazione. C'è poi una trappola correlata chiamata Ambient Context: una dipendenza statica e accessibile globalmente, come un ITimeProvider globale o un logger statico, a cui qualsiasi punto del codice può accedere liberamente. van Deursen racconta di grandi difficoltà avute con una libreria di logging statica proprio per questo motivo: la dipendenza era invisibile, impossibile da testare e creava accoppiamenti nascosti in tutto il codice, oltre a produrre un effetto collaterale sgradevole chiamato Accoppiamento temporale, dove il codice funziona correttamente solo se un'altra fase di configurazione invisibile è avvenuta prima, nell'ordine giusto, da qualche altra parte. Il filo conduttore di tutte queste trappole è sempre lo stesso: nascondere ciò da cui una classe dipende davvero finisce sempre per costarvi caro in seguito, anche se vi fa risparmiare un minuto adesso.

Capitolo 6

Cosa significa davvero "essere vivo" per un oggetto

Quando le dipendenze arrivano attraverso i costruttori a partire da una corretta Composition Root, emerge una nuova questione. Seemann nota che questo è uno dei punti che crea più confusione in assoluto: quanto deve durare esattamente un oggetto? È qui che entra in gioco il Ciclo di vita degli oggetti. Vale la pena spiegare questo concetto in modo molto semplice, perché la parola "ciclo di vita" lo fa sembrare astratto, quando in realtà è del tutto pratico. Ogni oggetto creato esiste per un certo intervallo di tempo, da quando viene costruito a quando viene eliminato dal garbage collector o distrutto esplicitamente. In un'applicazione fortemente accoppiata, questo intervallo è casuale, deciso implicitamente da qualsiasi punto in cui si trova la parola `new`. In un'applicazione ben strutturata, la Composition Root — o il Composer, come Seemann chiama il componente responsabile della gestione del ciclo di vita — prende questa decisione di proposito. E la decisione è importantissima, perché sbagliare causa bug difficilissimi da scovare: dati che trapelano tra richieste che dovrebbero essere isolate, connessioni al database condivise in modo scorretto che corrompono lo stato, o peggio, blocchi sotto carico che si verificano solo in produzione. Seemann individua tre stili principali di gestione del ciclo di vita. È utile analizzarli insieme, perché si capiscono davvero solo mettendoli a confronto. Il primo è il Singleton. Un'unica istanza, creata una volta sola e riutilizzata per tutta la durata dell'applicazione. Pensatelo come al boiler dell'acqua calda dell'intero condominio. Ogni appartamento attinge dallo stesso boiler. È una scelta efficiente, ma funziona in sicurezza solo se ciò che viene condiviso può gestire l'uso contemporaneo da parte di molti utenti diversi senza fare confusione, cioè se è thread-safe. L'esempio di Seemann è un repository di prodotti risiedente in memoria: un caso semplice in cui tenere un'unica istanza condivisa per tutta la vita dell'applicazione ha perfettamente senso, perché la copia dei dati è una sola e tutti devono vedere la stessa. Il secondo è Transient. Un'istanza nuova di zecca, ogni singola volta che qualcuno la richiede. Pensatela come a un bicchiere di carta usa e getta. Non lo lavate per darlo al cliente successivo: lo buttate e ne prendete uno nuovo dalla pila. È l'opzione più sicura nel senso che non rischierete mai di far trapelare dati tra parti diverse dell'applicazione, ma è anche la meno efficiente, dato che si paga continuamente il costo di costruzione dell'oggetto. Inoltre, se l'oggetto contiene risorse che richiedono pulizia, la distruzione diventa un aspetto da gestire con molta attenzione.

Vedi ogni parola mentre la ascolti

Segui la lettura senza sforzo mentre ogni parola del Riassunto di Dependency injection in .NET si illumina in tempo reale.

Capitolo 7

Il ciclo di vita che confonde tutti

Il terzo stile è Scoped, ed è quello che crea più problemi. Vale la pena rallentare e spiegarlo da zero, piuttosto che darne una definizione astratta sperando che rimanga impressa. Ecco il modo più semplice per spiegare cosa significa "scoped": un oggetto viene creato una volta sola e riutilizzato, ma soltanto per la durata di una specifica unità di lavoro, dopodiché sparisce. Non per sempre, come un Singleton. Non per una singola chiamata a un metodo, come un Transient. Soltanto per un episodio ben delimitato, per poi essere eliminato alla fine di quell'episodio. L'analogia che chiarisce tutto è questa: pensate a uno scope come alla sessione di un tavolo al ristorante. Quando i clienti si siedono, il ristorante assegna loro un cameriere per l'intero pranzo, dall'antipasto al dolce. Quel cameriere gestirà ogni portata, ogni richiesta d'acqua, i tovaglioli extra e il conto finale. Sarebbe assurdo cambiare cameriere per ogni singola interazione: sarebbe un uso esagerato dello stile Transient. Sarebbe altrettanto assurdo se quel singolo cameriere servisse tutti i tavoli del ristorante contemporaneamente per tutta la serata: sarebbe un Singleton a cui viene chiesto di fare qualcosa per cui non è stato progettato, finendo per crollare sotto il carico o per consegnare i piatti al tavolo sbagliato. Il ristorante crea invece un'assegnazione cameriere-tavolo per ogni cliente, usa quella stessa assegnazione per tutto il pranzo e la scioglie nel momento in cui i clienti pagano e se ne vanno. Il gruppo successivo allo stesso tavolo riceverà un'assegnazione del tutto nuova. L'esempio pratico di Seemann è il DbContext di Entity Framework Core, l'oggetto che rappresenta una connessione attiva e un'unità di lavoro verso un database. All'interno di una singola richiesta web, si vuole spesso che ogni parte del codice che tocca il database condivida la stessa identica istanza di DbContext, perché il DbContext tiene traccia delle modifiche. Se due parti diverse della richiesta ricevessero due istanze separate, non vedrebbero le modifiche pendenti l'una dell'altra, o finirebbero per aprire molte più connessioni al database del necessario. Ma non si vuole assolutamente che quella stessa istanza di DbContext venga riusata nella richiesta web successiva, arrivata più tardi da un altro utente, perché altrimenti i dati dell'utente precedente finirebbero per trapelare nella richiesta di qualcun altro. La richiesta web è lo scope. Un'unica istanza, condivisa per la durata di quella richiesta, eliminata al termine della richiesta stessa. Seemann mostra questo meccanismo con un piccolo esempio console chiamato CurrencyMonitoring, staccato da qualsiasi framework web, proprio per far vedere come funziona lo scoping senza distrazioni. Una classe chiamata Composer è responsabile della gestione di CommerceContext. Invece di rendere il DbContext un Singleton condiviso per tutta l'esecuzione del programma o un Transient ricostruito di continuo, il Composer definisce uno scope esplicito, cioè un blocco di codice delimitato. Lo avvia, esegue un lavoro correlato al suo interno condividendo un'unica istanza di CommerceContext, e poi chiude lo scope. Al giro successivo del ciclo di monitoraggio si apre un nuovo scope, con un nuovo CommerceContext. Il ciclo di vita non è legato né all'intera applicazione né alla singola piccola operazione, ma a un ciclo di lavoro ben delimitato. Sbagliare la gestione dello Scoped produce uno dei bug più rognosi di questa disciplina, che Seemann chiama Dipendenza prigioniera. Si verifica quando un oggetto a vita lunga, ad esempio un Singleton, tiene un riferimento a un oggetto a vita breve, cioè Scoped, come quel DbContext. Poiché il Singleton viene costruito una volta sola, prende l'istanza Scoped presente in quel momento e la trattiene per sempre, molto oltre il termine previsto per quel contesto. Il Singleton diventa una prigione, mantenendo la dipendenza Scoped prigioniera ben oltre la sua durata naturale. Il risultato è che un contesto di database vecchio o distrutto viene riutilizzato all'infinito in richieste con cui non dovrebbe avere nulla a che fare. La soluzione di Seemann nella DI pura è la disciplina strutturale: costruire i Singleton in un'unica fase ben separata all'avvio, e creare tutto ciò che è Scoped o Transient più tardi, dentro ogni nuova unità di lavoro, senza mai lasciare che un oggetto a vita lunga vada a prendersi un oggetto a vita breve per tenerlo con sé. C'è una seconda versione di questa trappola, che Seemann chiama Astrazione che perde dettagli riguardante la scelta del ciclo di vita. Si presenta ad esempio quando si avvolge una dipendenza in un `Lazy<T>` per ritardarne la creazione, ma quella scelta si riflette all'esterno, costringendo chiunque la usi a gestire la pigrizia della creazione invece di vedere semplicemente una normale dipendenza pronta all'uso. La soluzione consiste nell'usare un Virtual Proxy, cioè un oggetto sostitutivo con la stessa identica forma della dipendenza reale, che crea l'oggetto vero dietro le quinte solo quando serve davvero, così nessuno a valle deve sapere cosa stia succedendo. Una perdita simile si verifica con la gestione del ciclo di vita per singolo thread, dato che il codice asincrono moderno non rimane bloccato su un solo thread. Di conseguenza, tutto ciò che ha uno scope legato al "thread corrente" rischia di rompersi con l'esecuzione concorrente. La soluzione è associare lo scope alla reale unità di lavoro — la richiesta o l'operazione — e non a dettagli implementativi come il thread in esecuzione in quel momento. Tenete a mente l'immagine del ristorante, perché è il punto di riferimento più chiaro: il Singleton è il boiler unico dell'edificio, il Transient è il bicchiere di carta che si getta via ogni volta, e lo Scoped è il cameriere assegnato al vostro tavolo per la sola durata del vostro pranzo.

Capitolo 8

Il ciclo di vita Scoped, spiegato in modo semplice

I primi due cicli di vita sono semplici. Un oggetto transient è usa e getta: ogni volta che serve, ne viene creato uno nuovo. Un singleton è permanente: una sola istanza, creata all'inizio e usata per tutta la durata dell'applicazione. Lo scoped sta in mezzo, ed è quello che crea confusione perché non è definito dal tempo, ma da un confine. Pensate a un'istanza scoped come alla visita a un ristorante. Il cameriere assegnato al vostro tavolo è il vostro per tutto il pranzo, da quando vi sedete a quando pagate il conto. Ogni portata, ogni richiesta d'acqua, passa da quel cameriere. Ma quando vi alzate, quel cameriere passa ad altri. Se gli fate una domanda il giorno dopo, non si ricorderà di voi. Questo è lo Scoped: un'unica istanza, condivisa in modo coerente tra tutto ciò che accade dentro un'unità di lavoro definita — in genere una richiesta web in ingresso — e poi eliminata non appena quell'unità termina. Immaginate quindi una richiesta che arriva a un'applicazione web. Ha bisogno di una connessione al database racchiusa in un repository. Con un ciclo di vita Scoped, quel repository viene creato una volta sola per quella richiesta. Se tre classi diverse lungo la catena di chiamate ne hanno bisogno — un servizio prodotti, un calcolatore di prezzi, un validatore d'ordini — riceveranno tutte la stessa istanza, perché si trovano tutte nello stesso ristorante, durante lo stesso pranzo. Non appena la risposta torna al browser, quell'istanza viene eliminata. La richiesta successiva avrà il suo cameriere, il suo repository e la sua connessione al database. Perché questo aspetto è così importante? Perché una connessione al database o un contesto di tracciamento si comportano in modo molto diverso a seconda di quanto vivono. Se li condividete nel modo giusto dentro una richiesta, tutto rimane coerente: un'unica unità di lavoro e una vista coerente dei dati. Se li condividete male, si verifica l'errore a cui è dedicata interamente la sezione successiva.

Ottieni di più dal Riassunto di Dependency injection in .NET

Ricevi spunti ogni giorno da oltre 100.000 lezioni
Le parole si illuminano in sincronia con l'audio
La tua libreria salvata su ogni dispositivo

Capitolo 9

La trappola della dipendenza prigioniera

La Dipendenza prigioniera è una trappola che vale la pena conoscere con il suo nome reale, perché una volta compresa la noterete ovunque. Si verifica quando qualcosa creato per essere temporaneo rimane bloccato dentro qualcosa creato per durare per sempre. Ripensiamo al cameriere del ristorante, ma immaginiamo che il proprietario del locale — che è lì fisicamente giorno e notte — decida di prendere quel cameriere come suo assistente personale a vita. Quel cameriere non farà più i turni. Rimarrà bloccato lì per sempre, legato a qualcuno che non se ne va mai. Tradotto in codice: un servizio singleton, creato una volta sola e tenuto in vita per tutta l'esecuzione dell'applicazione, chiede un repository scoped nel suo costruttore. Lo riceve nel momento in cui viene costruito, e poi lo trattiene per sempre, dato che un singleton viene istanziato una volta sola. Il repository che doveva aggiornarsi a ogni richiesta diventa permanente, intrappolato, prigioniero. I danni di questa situazione non si vedono con un rapido test manuale. Emergono sotto carico, settimane dopo, quando due richieste web separate arrivano contemporaneamente e finiscono per toccare la stessa istanza prigioniera e la stessa connessione al database nello stesso momento, perché non è mai stata liberata e riassegnata come previsto. I dati diventano incoerenti, i thread si sovrappongono e il bug diventa difficilissimo da tracciare, perché presi singolarmente i componenti sembrano corretti. La soluzione è una regola sull'ordine dei componenti da ricordare sempre: il ciclo di vita di un componente non deve mai durare più a lungo del ciclo di vita di ciò da cui dipende. Un singleton può dipendere in sicurezza solo da altri singleton. Un oggetto scoped può dipendere da dipendenze scoped o singleton. Un oggetto transient può dipendere da qualsiasi cosa, perché non rimane in giro abbastanza a lungo da intrappolare nessuno. Seguendo questa regola, le dipendenze prigioniere smettono di essere un mistero e diventano facili da individuare a colpo d'occhio.

Capitolo 10

Costruire la Composition Root a mano

La gestione dei cicli di vita e la prevenzione delle dipendenze prigioniere devono avvenire in un posto concreto: la Composition Root. Ovvero l'unico punto, il più vicino possibile all'ingresso dell'applicazione, in cui l'intero grafo degli oggetti viene assemblato. Vediamo come si presenta tutto questo senza un container che faccia il lavoro al posto nostro, in uno stile chiamato DI pura. Fare DI pura significa scrivere i collegamenti a mano, in codice semplice, proprio nella radice dell'applicazione. Può sembrare quasi banale: un repository viene costruito, avvolto in un decorator, passato a un servizio e infine consegnato a un controller, tutto dentro un unico blocco di normale creazione di oggetti. Nessuna magia, nessun file di configurazione, nessuna reflection che analizza i componenti. Siete solo voi che scrivete cosa dipende da cosa, nell'unico posto dell'intero codice autorizzato a farlo. Ogni altra classe si limita ad accettare ciò che le viene passato dal costruttore, senza sapere come sia stato costruito. Solo la radice vede la forma completa dell'albero. Perché scegliere di collegare a mano un'intera applicazione invece di lasciarlo fare a un framework? Perché la DI pura mantiene tutto visibile al compilatore. Se rinominate un'interfaccia, ogni riferimento collegato a mano diventerà subito rosso, senza sorprese a runtime settimane dopo a causa di un container che non è riuscito a risolvere un componente. Per moltissime applicazioni questo approccio è più che sufficiente, ed è il punto di partenza consigliato perché non richiede strumenti aggiuntivi per essere compreso. Ma i grafi crescono. Collegare a mano centinaia di servizi con cicli di vita diversi e sostituzioni condizionali diventa faticoso. Quello è il momento giusto per introdurre un container, come Autofac, Simple Injector o la libreria più leggera Microsoft.Extensions.DependencyInjection inclusa di serie in ASP.NET Core. Nessuno di questi strumenti cambia l'architettura sottostante: si limitano ad automatizzare il lavoro che la Composition Root faceva a mano, cioè costruire il grafo, rispettare i cicli di vita e restituire l'oggetto pronto.

Vedi ogni parola mentre la ascolti

Segui la lettura senza sforzo mentre ogni parola del Riassunto di Dependency injection in .NET si illumina in tempo reale.

Capitolo 11

Decorator: aggiungere funzionalità senza toccare il codice principale

Una volta costruito il grafo e rispettati i cicli di vita, la struttura inizia a mostrare i suoi veri vantaggi. Mettiamo che serva aggiungere un log a ogni chiamata al repository. O che serva un circuito di protezione che fermi le chiamate verso un servizio che sta già fallendo. La tentazione sarebbe quella di aprire la classe reale e aggiungere il codice direttamente lì. Ma non fatelo. È esattamente il tipo di accoppiamento che questa architettura vuole evitare. Costruite invece una seconda classe che implementa la stessa identica interfaccia di quella reale e la avvolge. Immaginate una busta attorno a una lettera: la busta aggiunge un affrancatura, un mittente e un timbro postale, ma non tocca una singola parola del testo interno. Un decorator di logging attorno a un repository di prodotti fa la stessa cosa: implementa la medesima interfaccia, quindi chi lo chiama non nota alcuna differenza, ma prima e dopo aver inoltrato la chiamata al repository reale, scrive un log. La classe del repository reale non importa librerie di logging e non sa nemmeno che il logging esista. Svolge soltanto il suo lavoro. Il circuito di protezione funziona allo stesso modo. Avvolgete un inviatore di messaggi in un decorator che conta i fallimenti. Se si accumulano troppi errori, smette di provare a inviare i messaggi e blocca subito la chiamata, proteggendo il resto del sistema da un servizio in difficoltà. La classe reale che invia il messaggio non contiene alcuna riga di codice per il conteggio degli errori: non ha bisogno di sapere di essere protetta. E poiché ciascuno di questi componenti è un'ulteriore implementazione della stessa interfaccia, potete impilarli: un decorator di autorizzazione che avvolge un decorator di logging che avvolge il gestore reale. Tre livelli distinti, ognuno all'oscuro degli altri. Aggiungere una nuova funzionalità in seguito, o rimuoverne una, significa modificare un'unica riga nella Composition Root, senza toccare le classi che svolgono il lavoro aziendale vero e proprio. È questo il risultato di tutto ciò che abbiamo visto finora: l'iniezione nel costruttore, il punto di composizione unico e la disciplina nell'uso della parola chiave `new`. Niente di tutto questo era complicazione inutile: è ciò che rende possibili modifiche così pulite.

Capitolo 12

Cosa si guadagna alla fine

Ogni regola vista finora riconduce a un unico principio: le cose che cambiano per motivi diversi non dovrebbero essere saldate insieme. La libreria del database, la chiamata di log, il circuito di protezione e la logica aziendale che calcola il prezzo di un prodotto non devono stare nello stesso punto del codice. Tenendoli separati, ciascuno può cambiare, essere testato, essere sostituito o fallire, senza trascinare con sé tutti gli altri. È questo il vero vantaggio, e raramente lo si nota il giorno in cui si scrive il codice. Lo si nota più avanti, quando uno sviluppatore junior deve cambiare il tipo di database, aggiungere una chiave di funzionalità o tracciare un bug nei log di produzione, e scopre di poterlo fare toccando un singolo decorator, in un solo punto, senza il timore di rompere gli altri componenti collegati allo stesso oggetto. Al frigorifero nella vostra cucina non importa chi abbia prodotto il latte che contiene. E al vostro codice, scritto in questo modo, non importa chi abbia creato le sue dipendenze. Questa non è un'astrazione teorica: è la differenza tra un codice su cui potrete continuare a lavorare tra diversi anni e uno che avrete persino paura di aprire.

★★★★★

Hai raggiunto la fine del Riassunto di Dependency injection in .NET

“Sono passati 23 giorni e l'ho usata ogni giorno. Ora fa parte della mia routine quotidiana.”

jayallen

Temi chiave del Riassunto di Dependency injection in .NET

loose coupling
software maintainability
design pattern implementation
object composition
architectural seams

Le migliori citazioni dal Riassunto di Dependency injection in .NET

DI represents a fundamental shift in how we approach software design.
The fundamental purpose of DI is to write maintainable code.
Loose coupling through DI provides five key benefits.
Requirements inevitably change.
Over-abstraction can lead to unnecessary complexity.

Personaggi del Riassunto di Dependency injection in .NET

Mark SeemannAuthor and expert on software architecture

Sull'autore

Mark Seemann, acclamato autore di Dependency Injection in .NET e autorità leader nell'architettura del software, combina decenni di esperienza pratica nello sviluppo con un focus sulle pratiche di coding sostenibili. Co-fondatore di CloudCall Group Plc e titolare di brevetti nel settore delle telecomunicazioni, egli getta un ponte tra i concetti teorici e le applicazioni aziendali del mondo reale. Il suo lavoro pone l'accento sul clean code, sulla manutenibilità e sui paradigmi della programmazione funzionale, temi centrali nella sua guida alla dependency injection vincitrice del Jolt Award e nel libro complementare Dependency Injection: Principles, Practices, Patterns.

Oltre alla scrittura, Seemann condivide la sua esperienza attraverso il suo popolare blog ploeh, i corsi su Pluralsight e interventi in conferenze internazionali come l'NDC London. Le sue intuizioni sono state presentate su BBC News e CNBC, mentre i suoi design di framework influenzano gli sviluppatori nelle organizzazioni di tutto il mondo.

Con oltre 15 anni di creazione di contenuti e più di 100 talk tecnici, continua a plasmare le moderne pratiche del software. Dependency Injection in .NET rimane un testo fondamentale, tradotto in più lingue e utilizzato nei programmi di formazione professionale a livello globale.

Scarica il riassunto di Dependency injection in .NET

Ottieni il riassunto di Dependency injection in .NET in formato PDF o EPUB gratuito. Stampalo o leggilo offline quando vuoi.

Agli utenti è piaciuto anche

Dependency injection in .NET

Mark Seemann

Writing High-Performance .NET Code

Ben Watson

Copertina del libro Senior C# Vocabulary and the Systems That Survive

Design Patterns in C#: Which Ones Still Matter in 2026 | by Kerim Kara | Medium

Clean Architecture in C#: Practical Guide for .NET

.NET Architecture at Scale: Visual Guide to Modern Design Patterns | Nitin Singh | Enterprise AI & Architecture

6 sources

Senior C# Vocabulary and the Systems That Survive

Copertina del libro The Pragmatic Programmer: Lessons for Modern Developers

23 sources

The Pragmatic Programmer: Lessons for Modern Developers

Copertina del libro Spec-Driven AI Coding

Vibe Coding: How to Create the Perfect Prompts and Avoid AI Spaghetti Code | VibeMeta

Vibe Specs: Vibe Coding That Actually Works

Vibe Coding Best Practices for Building with AI in 2026

6 sources

Spec-Driven AI Coding

Copertina del libro Prompt Injection: The AI Double Agent

Prompt injection explained, November 2023 edition

Prompt Injection Explained: The AI Security Problem Most People Don’t See

Prompt Injection in Vibe-Coded Apps: OWASP LLM #1 Risk Explained — 18 Free Scans for Vibe-Coded Apps

Prompt Injection: 6 Attacks and 6 Defenses | aakashx

5 sources

Prompt Injection: The AI Double Agent

Programming C#

Jesse Liberty

Copertina del libro Rapid Landing Pages in Visual Studio

Create C# ASP.NET Core web application - Visual Studio (Windows)

Net Core 10: ASP.Net Razor Pages Hello World Tutorial [2026]

Tutorial: Get started with Razor Pages in ASP.NET Core

9 sources

Rapid Landing Pages in Visual Studio

Domande frequenti sul Riassunto di Dependency injection in .NET

Scopri di più

PIANO DI APPRENDIMENTO

The Diagnostic for Tool Enshittification

As software platforms increasingly prioritize monetization over utility, developers must learn to identify predatory technical patterns. This guide is essential for software architects and engineers who want to build resilient stacks and avoid becoming locked into decaying ecosystems.

1 h 30 m•3 Sezioni

PIANO DI APPRENDIMENTO

Designing and Programming Software

This comprehensive path is designed for developers looking to transition from writing scripts to engineering robust, production-ready systems. It provides the essential bridge between basic syntax and complex architectural decision-making required in modern tech roles.

5 h 53 m•4 Sezioni

PIANO DI APPRENDIMENTO

DevSecOps

As cyber threats evolve, security can no longer be a final checkpoint; it must be embedded into every stage of the software lifecycle. This plan is essential for developers, DevOps engineers, and security professionals looking to build resilient, automated, and compliant delivery pipelines.

5 h 2 m•4 Sezioni

PIANO DI APPRENDIMENTO

Programming

This comprehensive path bridges the gap between basic syntax and professional system architecture. It is ideal for aspiring developers who want to master both the practical skills of coding and the high-level design patterns used in top-tier tech companies.

5 h 1 m•4 Sezioni

PIANO DI APPRENDIMENTO

From Zero to Coder

This comprehensive path bridges the gap between digital literacy and professional software development. It is ideal for absolute beginners who want to move beyond basic syntax to building functional web applications with industry-standard tools.

2 h•5 Sezioni

PIANO DI APPRENDIMENTO

Learn software dev

This comprehensive learning path takes you from programming beginner to professional software engineer, covering everything from writing your first line of code to making architectural decisions for large-scale systems. It's ideal for career changers entering tech, self-taught programmers looking to formalize their skills, or junior developers aiming to reach senior-level expertise. The structured progression ensures you build both technical proficiency and the professional mindset needed to succeed in modern software development teams.

4 h 50 m•4 Sezioni

PIANO DI APPRENDIMENTO

Build Atomic JSON:API in .NET

This plan is essential for .NET developers building high-performance, standardized APIs that require complex data handling. It benefits backend engineers looking to implement the JSON:API spec and its powerful atomic operations extension for transactional consistency.

1 h 15 m•3 Sezioni

PIANO DI APPRENDIMENTO

Advanced Azure Development and AI Integration

This learning plan bridges the gap between traditional development and modern cloud-native approaches for technical professionals seeking to enhance their Azure expertise. It's ideal for consultants and developers who need to deliver enterprise-grade solutions while leveraging Microsoft's full technology stack including containers, low-code platforms, and AI services.

4 h 9 m•4 Sezioni

Creato da alumni della Columbia University | a San Francisco

BeFreed Riunisce Una Community Globale Di Menti Curiose

4.7

valutazione media

Oltre 7,84 mila valutazioni dell’app

Community BeFreed

Sul serio, non ho ancora esplorato l'app fino in fondo, ma dopo questi primi giorni sono davvero colpita… BeFreed è su un altro livello rispetto a qualsiasi altra app di apprendimento che abbia usato. Ti coinvolge tantissimo e migliora davvero la concentrazione: perfetta per chi non riesce a smettere di scrollare!

@ladyInfinity

Ho comprato BeFreed esattamente 23 giorni fa e da allora l'ho usata ogni singolo giorno. Si è integrata completamente nel mio flusso di lavoro e nelle mie abitudini di studio.

@jayallen

La verità è che l'app ha superato tutte le mie aspettative. Posso chiederle di generare audio su qualunque argomento, qualsiasi esso sia, e il risultato è impressionante. Il mio campo professionale è una specializzazione in psicoterapia, molto multidisciplinare; eppure le risposte sono molto accurate.

@Raguipa

Quello che apprezzo di più è quanto abbia ridotto il mio scrolling: passo meno tempo a cercare e più tempo ad assorbire informazioni. La combinazione di audiolibri completi, podcast e piani di apprendimento è brillante.

@colonyofcreatorsNGO

Sono istruttore di apprendimento accelerato PhotoReading da 24 anni… libri, lettura e apprendimento sono il mio pane, e BeFreed ha fatto un ottimo lavoro offrendo un approccio innovativo per trasmettere le informazioni in un modo facile da assimilare.

@BeFreed user

Non è solo un'app di riassunti di libri: ho usato l'opzione di lettura divertente ed è un riassunto molto migliore, un modo più efficace di afferrare le idee rispetto al metodo tradizionale. Solo questo vale la spesa.

@austinakon

Adoro questa app. La uso da diversi giorni e non riesco a smettere di ascoltare. Un ottimo modo per iniziare.

@jcrules328

Il programma mi piace davvero; lo sto provando da circa un mese e lo trovo una vera gemma. Funziona così bene perché con BeFreed posso creare i miei argomenti, e la voce è ottima, con una scelta illimitata di narrazioni.

@DanielCZ

Sul serio, non ho ancora esplorato l'app fino in fondo, ma dopo questi primi giorni sono davvero colpita… BeFreed è su un altro livello rispetto a qualsiasi altra app di apprendimento che abbia usato. Ti coinvolge tantissimo e migliora davvero la concentrazione: perfetta per chi non riesce a smettere di scrollare!

@ladyInfinity

Ho comprato BeFreed esattamente 23 giorni fa e da allora l'ho usata ogni singolo giorno. Si è integrata completamente nel mio flusso di lavoro e nelle mie abitudini di studio.

@jayallen

La verità è che l'app ha superato tutte le mie aspettative. Posso chiederle di generare audio su qualunque argomento, qualsiasi esso sia, e il risultato è impressionante. Il mio campo professionale è una specializzazione in psicoterapia, molto multidisciplinare; eppure le risposte sono molto accurate.

@Raguipa

Quello che apprezzo di più è quanto abbia ridotto il mio scrolling: passo meno tempo a cercare e più tempo ad assorbire informazioni. La combinazione di audiolibri completi, podcast e piani di apprendimento è brillante.

@colonyofcreatorsNGO

Sono istruttore di apprendimento accelerato PhotoReading da 24 anni… libri, lettura e apprendimento sono il mio pane, e BeFreed ha fatto un ottimo lavoro offrendo un approccio innovativo per trasmettere le informazioni in un modo facile da assimilare.

@BeFreed user

Non è solo un'app di riassunti di libri: ho usato l'opzione di lettura divertente ed è un riassunto molto migliore, un modo più efficace di afferrare le idee rispetto al metodo tradizionale. Solo questo vale la spesa.

@austinakon

Adoro questa app. La uso da diversi giorni e non riesco a smettere di ascoltare. Un ottimo modo per iniziare.

@jcrules328

Il programma mi piace davvero; lo sto provando da circa un mese e lo trovo una vera gemma. Funziona così bene perché con BeFreed posso creare i miei argomenti, e la voce è ottima, con una scelta illimitata di narrazioni.

@DanielCZ

Adoro poter ricevere informazioni e idee utili e condensate in un audio in stile podcast da 8-15 minuti. Non sono un grande fan dei podcast per via di tutto il riempitivo, ma qui si va dritti al punto.

@BeFreed user

Sto finendo il dottorato e devo leggere un sacco di materiale che non conosco… Con BeFreed basta inserire un prompt: l'app trova le fonti per te e genera un podcast audio. Trovo il processo di BeFreed più scorrevole di NotebookLM.

@Brad

Cerco spesso su YouTube qualcosa da ascoltare mentre preparo la colazione, cammino o sono in viaggio, e BeFreed offre un approccio ancora più mirato, senza pubblicità e senza riempitivi!

@BeFreed user

La cosa in assoluto migliore di questa piattaforma è la versatilità. Non c'è letteralmente nessun argomento fuori portata. Gestisce qualsiasi cosa le proponi… È raro trovare uno strumento di apprendimento senza limiti che mantenga davvero le promesse.

@jayallen

BeFreed è fantastica. Il design intuitivo mi fa passare meno tempo a navigare e più tempo a imparare. Il mix di audiolibri, podcast e piani di apprendimento è una combinazione geniale che ha cambiato completamente la mia routine quotidiana.

@BeFreed user

All'inizio mi ci è voluto un po' per capire come creare podcast in italiano e poi… boom! È fantastico! Posso chiedergli di spiegarmi qualsiasi argomento e lo fa benissimo, con grande intelligenza!

@matteo77

BeFreed è diventata la mia app quotidiana per gli audiolibri… Quello che mi piace di più è che inserisci il tuo testo e ottieni un audio da ascoltare ovunque.

@kotanzu1

Adoro poter ricevere informazioni e idee utili e condensate in un audio in stile podcast da 8-15 minuti. Non sono un grande fan dei podcast per via di tutto il riempitivo, ma qui si va dritti al punto.

@BeFreed user

Sto finendo il dottorato e devo leggere un sacco di materiale che non conosco… Con BeFreed basta inserire un prompt: l'app trova le fonti per te e genera un podcast audio. Trovo il processo di BeFreed più scorrevole di NotebookLM.

@Brad

Cerco spesso su YouTube qualcosa da ascoltare mentre preparo la colazione, cammino o sono in viaggio, e BeFreed offre un approccio ancora più mirato, senza pubblicità e senza riempitivi!

@BeFreed user

La cosa in assoluto migliore di questa piattaforma è la versatilità. Non c'è letteralmente nessun argomento fuori portata. Gestisce qualsiasi cosa le proponi… È raro trovare uno strumento di apprendimento senza limiti che mantenga davvero le promesse.

@jayallen

BeFreed è fantastica. Il design intuitivo mi fa passare meno tempo a navigare e più tempo a imparare. Il mix di audiolibri, podcast e piani di apprendimento è una combinazione geniale che ha cambiato completamente la mia routine quotidiana.

@BeFreed user

All'inizio mi ci è voluto un po' per capire come creare podcast in italiano e poi… boom! È fantastico! Posso chiedergli di spiegarmi qualsiasi argomento e lo fa benissimo, con grande intelligenza!

@matteo77

BeFreed è diventata la mia app quotidiana per gli audiolibri… Quello che mi piace di più è che inserisci il tuo testo e ottieni un audio da ascoltare ovunque.

@kotanzu1

Scopri di piu su come si parla di BeFreed nel web