Corso Entity Framework con il metodo SVILUPPATORE MIGLIORE
Padroneggia l'ORM di riferimento nell'ecosistema .NET. Query performanti, migrazioni controllate e architetture dati che reggono la produzione.
Mentore 1 a 1 Sul TUO codice Risultati misurabili
Il tuo team usa Entity Framework. Ma lo usa bene?
Nella nostra esperienza, la risposta è quasi sempre no. La maggior parte dei team .NET usa EF Core come un generatore di query SQL automatico, senza capire cosa succede sotto il cofano. Il risultato: query N+1, loading strategy sbagliate, migrazioni che rompono la produzione e performance che degradano man mano che i dati crescono.
Entity Framework Core è uno strumento potentissimo, se sai come usarlo. Ma usato male è una bomba a orologeria nel tuo codice.
Se sei un CTO che vede le performance del database degradare sprint dopo sprint, un team leader che vuole introdurre pattern solidi per l'accesso dati, o uno sviluppatore senior che vuole padroneggiare EF Core a livello avanzato, questo percorso è progettato per te.

Cosa impari: il programma completo
2 fasi, 8 moduli di formazione intensiva sul TUO codice.

2 fasi, 8 moduli di formazione intensiva sul TUO codice.
FASE 1: Fondamenta EF Core (Settimane 1-4)
- 1
Come EF Core vede il tuo database, e come assicurarti che non si sbagli
Il DbContext è il contratto tra il tuo codice e il database. Configurarlo a metà, con convenzioni implicite e mapping che sembrano funzionare, è il modo più rapido per ritrovarsi nei guai. Dopo 6 mesi di sviluppo, il mapping implicito produce uno schema che non corrisponde al domain model e migrazioni ingestibili che nessuno vuole toccare. In questo modulo si costruisce la configurazione esplicita, leggibile e manutenibile fin dal primo giorno.
Programma
- Ciclo di vita del DbContextCome impostare lo scoping per richiesta in ASP.NET Core, quando attivare il context pooling per abbattere il costo di allocazione sotto carico e perché condividere la stessa istanza tra più thread non è un rischio da valutare ma un errore che prima o poi genera dati corrotti
- Fluent API al posto delle Data AnnotationCome descrivere entità complesse con owned type, value object e table splitting mantenendo le classi di dominio pulite, senza annotazioni sparse che mescolano regole di persistenza e logica di business nello stesso file
- Configurazione separata con IEntityTypeConfigurationCome spostare il mapping di ogni entità in una classe dedicata, così da avere un OnModelCreating di poche righe invece di un metodo da 500 righe che nessuno osa più modificare
- Strategie di ereditarietà TPH, TPT e TPCCosa genera davvero ciascuna a livello di schema SQL, quale scegliere in base al rapporto tra numero di sottotipi e frequenza delle query, e quali costi di join o di colonne nullable nascondono
- Shadow property e backing fieldCome mappare colonne del database su proprietà che il dominio non espone all'esterno, per gestire chiavi esterne, timestamp e stato interno senza sporcare l'interfaccia pubblica delle entità
- Filtri di query globaliCome applicare in un solo punto le condizioni di multi-tenancy e di soft delete, così che vengano aggiunte automaticamente a ogni query e non ci sia modo di dimenticarle in un endpoint distratto
Risultato
Il database è mappato correttamente fin dal primo giorno. Il DbContext è pulito, ogni entità è configurata in modo esplicito e le migrazioni future non riservano sorprese.
- 2
Perché il database va piano (e non è colpa del server)
La scena è sempre la stessa: l'applicazione è lenta, il DBA dice che le query sono ok, gli sviluppatori dicono che il codice è ok. Nel mezzo c'è EF Core che sta generando SQL che nessuno ha mai letto, spesso trasformando una semplice pagina in decine di query non necessarie. Qui si abilita il query logging, si legge il SQL generato e si risolve alla radice.
Programma
- Logging delle query generateCome attivarlo e leggere l'SQL che EF produce davvero, la prima verifica da fare quando qualcosa è lento e quasi l'unica che nessuno esegue, perché si dà per scontato che il codice C# rispecchi la query eseguita
- Proiezioni con SelectLa differenza concreta tra caricare 50 colonne e caricarne 3, perché EF materializza l'intera entità se non gli dici esplicitamente quali campi ti servono, e quanto pesa questo su liste e pagine con molti record
- IQueryable contro IEnumerableLa singola riga che decide se il filtro viene tradotto in WHERE ed eseguito dal database oppure applicato in memoria dopo aver scaricato 200.000 record, cioè la differenza tra una query istantanea e un timeout
- Split queryQuando spezzare una query con molti Include in più comandi elimina la moltiplicazione cartesiana delle righe e guadagna secondi, e quando invece i round-trip aggiuntivi peggiorano la situazione
- Query compilateCome precompilare una query una volta sola ed eseguirla migliaia di volte senza ripagare ogni volta il costo di parsing e costruzione dell'albero, tecnica che ripaga sui percorsi critici ad alta frequenza
- Tag delle queryCome agganciare un'etichetta leggibile all'SQL generato, così da ritrovare subito nei log di produzione la query responsabile di un rallentamento invece di provare a indovinare quale delle decine eseguite sia la colpevole
Risultato
Quando la pagina lenta diventa veloce, sai esattamente perché. Leggi il SQL generato da EF come se lo avessi scritto a mano. Nessun mistero sotto il cofano.
- 3
Il problema N+1: il killer silenzioso che rallenta le applicazioni senza farsi vedere
Funziona in sviluppo. Funziona in staging. Ma in produzione, con dati reali, l'applicazione fa 500 query invece di 1. Il problema N+1 è il bug di performance più comune e più difficile da individuare nei codebase EF Core, e nella maggior parte dei casi nessuno lo sa fino al primo carico reale. Qui impari a riconoscerlo, diagnosticarlo e risolverlo in modo definitivo.
Programma
- Include e ThenIncludeCome indicare a EF quali relazioni caricare in un'unica query, invece di lasciare che ne emetta una per ogni entità trovata, e come navigare più livelli di relazioni senza far esplodere il numero di comandi
- Caricamento esplicitoCome caricare una relazione solo nel momento in cui serve davvero, utile nei casi in cui il caricamento eager porterebbe dietro dati che nella maggior parte delle richieste non vengono nemmeno usati
- Lazy loadingCome funziona dietro le quinte con i proxy, perché in quasi tutti gli scenari enterprise trasforma un ciclo innocuo in centinaia di query nascoste, e quei pochi casi in cui abilitarlo ha davvero senso
- AsSplitQuery contro query singolaI compromessi reali di performance, meno righe duplicate trasferite dalla rete da una parte, più viaggi verso il database dall'altra, e come decidere in base alla forma dei dati
- Interceptor per il monitoraggioCome registrare automaticamente ogni query che supera una soglia di tempo, in modo da accorgersi dei problemi di performance dai log prima che se ne accorgano gli utenti
- MiniProfiler integratoCome vedere in tempo reale, pagina per pagina, quante query vengono eseguite e quanto durano, trasformando il problema N+1 da invisibile a evidente in pochi secondi
Risultato
Zero query nascoste che ammazzano le performance in silenzio. Ogni operazione di caricamento dati è consapevole, ottimizzata e verificata.
- 4
Le migrazioni che non rompono la produzione: mai
Le migrazioni EF Core sono lo strumento giusto per versionare il database. Ma in un team con più sviluppatori e branch paralleli diventano rapidamente una fonte di conflitti. Un rollback di emergenza il sabato sera per una migrazione mal gestita è il tipo di esperienza che cambia per sempre il modo in cui un team approccia il database. In questo modulo si costruisce la strategia di migrazione che elimina questa categoria di problemi.
Programma
- Strategia di migrazione per il teamCome evitare i conflitti che nascono quando due sviluppatori modificano il modello in parallelo su branch diversi, con regole chiare su chi genera le migrazioni e come si integrano al momento del merge
- Popolamento dei dati inizialiQuando usare HasData per i dati di lookup stabili e quando invece serve un seeding scritto in codice per i dati che dipendono da logica di business o da altri record già presenti
- Migration bundleCome impacchettare le migrazioni in un eseguibile autonomo per il deployment automatizzato, senza dover installare gli strumenti a riga di comando di EF sul server di produzione
- Rollback e migrazioni idempotentiCome scrivere migrazioni che si possono applicare due volte senza danni, requisito fondamentale per le pipeline di deployment automatico dove uno stesso script può essere rieseguito
- Ambienti multipliCome gestire in modo controllato le differenze tra sviluppo, staging e produzione, evitando l'unico script generico che finisce per funzionare male dappertutto
- Confronto degli schemi e rilevamento del driftCome accorgersi che il database di produzione si è allontanato dal modello EF, individuando la deriva prima che diventi una migrazione che fallisce a metà
Risultato
Il deploy del database è un evento noioso, non un momento di tensione. Le migrazioni si applicano automaticamente, i conflitti vengono rilevati subito e il rollback è sempre possibile.
FASE 2: Architettura e Scenari Avanzati (Settimane 5-8)
- 5
Repository pattern sì o no? La risposta definitiva (con il codice per dimostrarla)
Pochi argomenti dividono i developer .NET quanto il Repository pattern con EF Core. Chi dice che serve per l'astrazione e il testing. Chi dice che DbContext è già un Unit of Work. Il dibattito non si risolve con opinioni: si risolve analizzando il tuo contesto specifico con dati concreti e conseguenze misurabili. Qui si risponde definitivamente con codice, scenari reali e motivazioni tecniche solide.
Programma
- Pattern RepositoryQuando aggiunge valore reale, tipicamente con più sorgenti dati o con la necessità di testare senza database, e quando invece è solo un wrapper che ripete l'API di EF aggiungendo righe senza dare nulla in cambio
- Unit of Work già incluso nel DbContextCome EF Core implementi di fatto questo pattern con il change tracker e il SaveChanges, e perché reimplementarlo sopra introduce bug sottili di gestione del ciclo di vita
- Pattern SpecificationCome rendere le query riutilizzabili e componibili, incapsulando i criteri di filtro in oggetti dedicati senza far uscire IQueryable dal layer di accesso ai dati
- CQRS con EF CoreCome separare un modello di lettura ottimizzato a colpi di proiezioni da un modello di scrittura che sfrutta il change tracker, dando a ciascuno la forma più adatta al proprio compito
- Eventi di dominio con MediatRCome pubblicare gli eventi solo dopo che la transazione è stata confermata, tenendo il dominio disaccoppiato dall'infrastruttura di messaggistica
- Più DbContext per bounded contextCome separare moduli diversi con context distinti, che puntino allo stesso database o a database separati, mantenendo confini netti tra le parti dell'applicazione
Risultato
Architettura dati chiara e testabile, senza layer inutili. Ogni scelta architetturale è motivata da un requisito concreto, non da un pattern applicato per abitudine.
- 6
Il bug che distrugge i dati degli utenti: concorrenza gestita senza paura
Due utenti aprono lo stesso record, lo modificano, salvano. Chi vince? Chi perde? Chi non sa nemmeno di aver perso le modifiche? La concorrenza è il bug più difficile da riprodurre in sviluppo e il più costoso in produzione, perché emerge solo con utenti reali e dati reali. Qui si costruisce la gestione della concorrenza che protegge i dati degli utenti in qualsiasi scenario.
Programma
- Concorrenza ottimistica con RowVersionCome fare in modo che EF Core sollevi un'eccezione invece di sovrascrivere in silenzio le modifiche di un altro utente, trasformando una perdita di dati invisibile in un conflitto che puoi gestire
- Risoluzione dei conflittiCome scegliere consapevolmente se far prevalere il client, il server o mostrare la differenza all'utente, decidendo la politica a monte invece di lasciare che il risultato dipenda dal caso
- Ambito transazionale e livelli di isolamentoLa differenza pratica tra Serializable e Read Committed e perché la scelta sbagliata porta da un lato a deadlock, dall'altro a letture sporche difficili da riprodurre
- Pattern OutboxCome garantire che un evento venga pubblicato se e solo se la transazione va a buon fine, eliminando sia i messaggi persi sia quelli duplicati che nascono quando database e broker non sono allineati
- IdempotenzaCome costruire operazioni che, richiamate dieci volte, producono lo stesso effetto di una sola, requisito indispensabile per i retry automatici e le code distribuite
- Transazioni distribuitePerché conviene evitarle quasi sempre e quali pattern adottare in alternativa per mantenere la consistenza tra più sistemi senza pagarne il costo in complessità e blocchi
Risultato
Puoi guardare in faccia un CTO e dirgli: i dati degli utenti non si perdono mai, anche con 500 utenti concorrenti. E hai la codebase per dimostrarlo.
- 7
Come testare il codice che tocca il database senza impazzire
Testare codice che parla con un database è il punto in cui la maggior parte dei team si arrende e lascia il data layer senza test. Ma testare senza un database reale porta a test che non rilevano i bug reali: la differenza tra InMemory provider e SQL Server in produzione è enorme. Qui si trova l'equilibrio con strumenti che rilevano i bug veri senza rallentare la suite.
Programma
- Provider InMemoryCosa verifica davvero e cosa non è in grado di verificare, perché affidarsi troppo a lui fa passare test verdi che poi si rompono sul SQL reale di produzione, dove vincoli e tipi si comportano diversamente
- SQLite in memoriaCome avvicinarsi al comportamento di SQL Server con un overhead minimo, e dove restano differenze di cui tenere conto per non farsi ingannare da un test che passa
- TestContainersCome avviare un vero SQL Server o PostgreSQL in Docker per i test di integrazione e distruggere il container al termine, ottenendo un database reale e usa e getta senza alcuna pulizia manuale
- Costruttori di dati di testCome comporre oggetti di test complessi in modo leggibile, con builder espliciti al posto di metodi factory da venti parametri in cui nessuno capisce più cosa rappresenta ciascun valore
- Test di integrazione con WebApplicationFactoryCome esercitare l'intera pipeline applicativa, connessione reale al database inclusa, in un test che resta leggibile in una decina di righe e verifica il comportamento vero dell'endpoint
- Test di performance sulle query criticheCome misurare in modo automatico che le query più importanti non peggiorino da una release all'altra, intercettando le regressioni prima che arrivino agli utenti
Risultato
Il data layer è testato con strumenti che rilevano i bug reali. Le regressioni sul database le trovi nei test, non in produzione a mezzanotte.
- 8
Quando EF Core non basta: come aggirarlo senza perderne i vantaggi
EF Core è lo strumento giusto per il 90% dei casi. Per il restante 10%, bulk operations, query complesse, stored procedure legacy, database NoSQL, servono strumenti diversi. Sapere quando uscire da EF Core e come farlo senza smontare l'architettura è la competenza che separa i senior dagli sviluppatori che dipendono da un solo strumento. Qui impari a usare tutti gli strumenti disponibili nel momento giusto.
Programma
- FromSql, SqlQuery ed ExecuteSqlCome eseguire SQL scritto a mano mantenendo attivo il change tracker e la sicurezza dei tipi sui risultati, per i casi in cui LINQ non basta ma non vuoi rinunciare ai vantaggi di EF
- Stored procedure e funzioni del databaseCome richiamarle in modo tipizzato e integrarle con il resto del layer dati, riutilizzando la logica già presente nel database legacy senza duplicarla nel codice
- Inserimenti e aggiornamenti massivi con EFCore.BulkExtensionsCome scrivere 10.000 record in un paio di secondi anziché nei minuti che servirebbero passando da SaveChanges un'entità alla volta
- Interceptor per audit trail e soft delete automaticoCome aggiungere comportamenti trasversali al layer dati, come tracciare chi ha modificato cosa o marcare i record come cancellati, senza toccare il codice applicativo esistente
- Diagnostica e ottimizzazione del change trackerCome capire cosa sta effettivamente tracciando EF, quando conviene usare AsNoTracking per le sole letture e come ridurre l'overhead di tracking sulle query più pesanti
- Provider per Cosmos DBCome usare EF Core con un database NoSQL mantenendo lo stesso modello di programmazione del relazionale, e dove invece il paradigma a documenti impone di ragionare diversamente
Risultato
Padroneggi tutti gli strumenti per qualsiasi scenario di accesso dati. Non sei mai bloccato da un limite di EF Core: sai esattamente come aggirarlo e quando è il momento giusto.
Il metodo: Architettura della Maestria Progressiva
Partiamo dal vostro codice EF Core esistente. Analizziamo le query più lente, identifichiamo gli anti-pattern e costruiamo insieme le best practice per il vostro contesto specifico.
Non è un corso teorico su EF Core. È un percorso per trasformare il modo in cui il vostro team gestisce i dati, con risultati misurabili in performance e manutenibilità.
A chi è rivolto questo percorso
Sviluppatore che vuole padroneggiare EF Core
Usi Entity Framework ma sai che c'è di più sotto il cofano. Vuoi capire le query generate, ottimizzare le performance e usare le feature avanzate che fanno la differenza.
Team con problemi di performance sul database
Le query sono lente, il database è un collo di bottiglia e nessuno sa esattamente perché. Vuoi un esperto che analizzi il tuo uso di EF Core e ti guidi verso la soluzione.
CTO che vuole un data layer enterprise-grade
Il layer dati è il cuore delle tue applicazioni. Vuoi best practice consolidate, migrazioni sicure e un team che sappia gestire la complessità dei dati.
Chi è Matteo Migliore
Cosa dicono i professionisti che hanno seguito il percorso
Investimento e percorso
I percorsi sono strutturati su misura in base al numero di partecipanti, durata e complessità del progetto.
Compila il modulo per ricevere il programma completo e un preventivo personalizzato in base alle tue esigenze specifiche.
Percorso Individuale
1 partecipante, mentoring personalizzato
- 8 moduli completi
- Sessioni live bisettimanali 1-to-1
- Accesso piattaforma 12 mesi
- Supporto continuo via chat
Percorso Team
2-3 partecipanti, trasformazione di reparto
- 8 moduli completi
- Lavoro su codebase aziendale
- Analisi query reali del progetto
- Accesso piattaforma 12 mesi per tutti
Workshop Intensivo
1-2 giorni su temi specifici
- Focus su performance o migrazioni
- Fino a 5 partecipanti
- Materiale didattico completo
- Sessione follow-up a 30 giorni
Pronto a padroneggiare Entity Framework Core?
Compila il modulo e ricevi tutte le informazioni sul percorso EF Core. Analizziamo il tuo scenario e il percorso migliore per te o il tuo team.
Analisi gratuita Valutiamo il vostro data layer attuale e le criticità principali
Parli con un nostro tutor Non con un commerciale, ma con un vero esperto che ti seguirà
Indicazioni pratiche Ricevi indicazioni utili anche se decidi di non proseguire
Domande frequenti
Sì, se usato correttamente. Il percorso insegna le tecniche di ottimizzazione avanzate (proiezioni, query compilate, batching) che permettono a EF Core di gestire carichi enterprise senza compromessi.
La durata è personalizzata in base agli obiettivi e al livello del team. I percorsi tipici vanno da 3 a 6 mesi, con sessioni bisettimanali.
Perfettamente. Il percorso include moduli specifici di ottimizzazione e refactoring di query esistenti, oltre a strategie di caching e accesso dati avanzato.
Sessioni live bisettimanali con accesso alla piattaforma con materiali, registrazioni e esempi avanzati. Non è un corso preregistrato, è affiancamento dal vivo su codice reale.
Il programma copre EF Core avanzato, migrazioni, query LINQ ottimizzate, proiezioni, query compilate, gestione delle relazioni, pattern Repository e Unit of Work, concorrenza e transazioni, bulk operations, raw SQL, audit e soft delete, testing con database in-memory. Ogni argomento viene affrontato su codice reale.
Non è un corso preregistrato con video generici. È un percorso di mentoring dal vivo, condotto da un architetto software con esperienza reale su progetti enterprise con EF Core.
Sì. Il percorso è sempre aggiornato all'ultima versione stabile di EF Core e .NET.
Assolutamente sì. Prima dell'inizio valutiamo le competenze del team e gli obiettivi di business. Possiamo approfondire performance, migrazioni, architettura dati o qualsiasi altro tema rilevante.
Le sessioni si svolgono in videoconferenza dal vivo, con condivisione schermo e lavoro diretto sul codice. Ogni sessione viene registrata e resa disponibile sulla piattaforma.
Il percorso è progettato per team da 2 a 12 persone. Per team più grandi possiamo organizzare sessioni parallele.
Sì, al completamento del percorso ogni partecipante riceve un attestato di partecipazione.
Il costo dipende dalla durata, dal numero di partecipanti e dal livello di personalizzazione richiesto. Contattaci per ricevere un preventivo su misura.


