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
- DbContext lifecycleScoping in ASP.NET Core, pooling per performance, concurrency e perché non condividerlo tra thread è una regola, non un suggerimento
- Fluent API invece dei Data AnnotationCome descrivere entità complesse con owned types, value objects e table splitting senza inquinare le classi di dominio
- IEntityTypeConfigurationCome separare il mapping di ogni entità in una classe dedicata invece di avere un OnModelCreating di 500 righe
- Strategie di ereditarietà TPH, TPT, TPCCosa generano davvero a livello SQL, quale scegliere e quali problemi di performance nascondono
- Shadow properties e backing fieldsCome mappare colonne del database a proprietà interne che il dominio non espone all'esterno
- Global query filtersCome applicare filtri di multi-tenancy e soft delete in un unico punto, senza dimenticarseli mai più in nessuna query
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
- Query loggingCome abilitarlo e leggere il SQL generato, la prima cosa da fare quando EF è lento e che quasi nessuno fa davvero
- Proiezioni con SelectLa differenza tra caricare 50 colonne e 3, perché EF carica tutto se non lo fermi tu esplicitamente
- IQueryable vs IEnumerableLa riga che decide se il filtro avviene nel database oppure dopo aver caricato 200.000 record già in memoria
- Split queriesQuando dividere una query complessa con molti Include guadagna secondi e quando invece peggiora le cose
- Compiled queriesPrecompila la query una volta, eseguila migliaia di volte senza overhead di parsing per i path critici ad alta frequenza
- Query tagsAggiungi un'etichetta leggibile al SQL generato per trovarlo subito nei log di produzione invece di indovinare quale query causa il problema
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 dire a EF di caricare le relazioni necessarie in un'unica query invece di una per ogni entità trovata
- Explicit loadingCome caricare relazioni on-demand solo quando servono, per i casi in cui il caricamento eager sarebbe uno spreco
- Lazy loadingCome funziona, perché nella stragrande maggioranza dei casi enterprise è una trappola e quando invece ha senso abilitarlo
- AsSplitQuery vs query singolaI trade-off di performance concreti, meno dati duplicati contro più round-trip al database
- Interceptors per monitoraggioCome loggare automaticamente tutte le query che superano una soglia di tempo in produzione
- MiniProfiler integratoCome visualizzare in tempo reale quante query sta facendo ogni pagina della tua applicazione
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
- Migration strategy per teamCome evitare conflitti quando due developer modificano il modello in parallelo su branch diversi
- Data seedingHasData per dati di lookup stabili contro seeding custom in codice per dati dipendenti da logica di business
- Migration bundlesCome pacchettizzare le migrazioni in un eseguibile per deployment automatizzato senza dipendere da EF CLI sul server
- Rollback strategy e migrazioni idempotentiCome costruire migrazioni che puoi eseguire due volte senza danni, fondamentale per deployment automatizzati
- Ambienti multipliCome gestire migrazioni diverse per sviluppo, staging e produzione senza un unico script che funziona male ovunque
- Schema comparison e database driftCome rilevare quando il database di produzione si è allontanato dal modello EF, prima che diventi un problema
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
- Repository patternQuando aggiunge valore reale, applicazioni con più data source e testing senza database, e quando è solo un wrapper inutile
- Unit of Work con DbContextCome EF Core implementa già questo pattern e perché duplicarlo introduce bug sottili di lifetime management
- Specification patternCome rendere le query riusabili e componibili senza esporre IQueryable fuori dal layer dati
- CQRS con EF CoreRead model ottimizzato con proiezioni e query separate dal write model che usa il change tracker
- Domain events con MediatRCome pubblicare eventi di dominio dopo che la transazione è stata committata, senza accoppiare il dominio all'infrastruttura
- Multi-DbContext per bounded contextCome separare moduli con DbContext diversi che puntano allo stesso o a database separati
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
- Optimistic concurrency con RowVersionCome fare in modo che EF Core lanci un'eccezione invece di sovrascrivere silenziosamente i dati di un altro utente
- Conflict resolutionScegliere consapevolmente tra vince il client, vince il server o mostra la differenza all'utente, invece di lasciare che accada per caso
- Transaction scope e isolation levelsLa differenza tra Serializable e Read Committed e perché scegliere sbagliato causa deadlock oppure dirty read
- Outbox patternCome garantire che l'evento venga pubblicato se e solo se la transazione è andata a buon fine, senza messaggi persi né duplicati
- IdempotencyCome costruire operazioni che puoi chiamare 10 volte con lo stesso effetto di 1, fondamentale per retry automatici e code distribuite
- Distributed transactionsPerché evitarle quasi sempre e quali pattern usare in alternativa per mantenere la consistenza
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
- InMemory providerCosa testa davvero e cosa NON testa, perché fidarsi troppo di lui porta a sorprese con SQL reale
- SQLite in-memoryCome avvicinarsi al comportamento di SQL Server con overhead minimo e dove ancora differisce
- TestContainersAvvia un SQL Server o PostgreSQL reale in Docker per i test di integrazione e distruggi il container al termine senza cleanup manuale
- Test data buildersCome costruire oggetti di test complessi in modo leggibile senza metodi factory con 20 parametri
- Integration test con WebApplicationFactoryTesta l'intera pipeline applicativa inclusa la vera connessione al database in un test che si legge in 10 righe
- Performance test delle query criticheCome misurare automaticamente che le query importanti non degradano tra una release e l'altra
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 e ExecuteSqlCome eseguire SQL diretto mantenendo il change tracker attivo e la sicurezza dei tipi sui risultati
- Stored procedures e funzioni databaseCome chiamarle in modo type-safe e integrarle con il resto del data layer
- Bulk insert e update con EFCore.BulkExtensionsCome inserire 10.000 record in 2 secondi invece di 4 minuti con SaveChanges
- Interceptors per audit trail e soft delete automaticoCome aggiungere comportamenti cross-cutting al layer dati senza toccare il codice applicativo
- Change tracker diagnostics e ottimizzazioneCome capire cosa sta tracciando EF, quando usare AsNoTracking e come ridurre l'overhead di tracking
- Cosmos DB providerCome usare EF Core con database NoSQL mantenendo lo stesso modello di programmazione del relazionale
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é. Volete un esperto che analizzi il vostro uso di EF Core e vi guidi verso la soluzione.
CTO che vuole un data layer enterprise-grade
Il layer dati è il cuore delle vostre applicazioni. Volete 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.