Accesso ai dati in .NET quando performance, coerenza e manutenzione contano davvero

Il data layer non è un dettaglio: è dove si perde il controllo

La maggior parte dei problemi di performance e manutenibilità nei sistemi .NET che analizzo ha origine nello strato dati.

Non nel modello di dominio, non nell'architettura applicativa: nel modo in cui si accede al database.

Query N+1 generate senza accorgersene da Entity Framework.

Caricamento di interi oggetti quando servono tre campi.

Transaction aperte per tutta la durata di una richiesta HTTP.

Indici mancanti su colonne usate in ogni WHERE clause.

Mapping tra tabelle e oggetti che forza strutture di query innaturali.

Questi non sono errori rari.

Sono pattern ricorrenti in quasi ogni codebase che cresce senza attenzione al data layer.

Il problema non è Entity Framework: è usarlo senza capire cosa genera.

Questa categoria esiste per colmare questo gap: non tutorial su come configurare il DbContext, ma ragionamenti su come progettare l'accesso ai dati in modo che il sistema rimanga veloce, coerente e modificabile mentre i requisiti cambiano.

Entity Framework Core: quando usarlo bene e quando affiancarlo a Dapper

Entity Framework Core è lo strumento giusto per la maggior parte dei scenari di accesso ai dati in .NET.

Gestisce il mapping, il change tracking, le migrazioni e l'astrazione dal dialetto SQL specifico.

Per operazioni CRUD, query moderate e manutenzione del schema, è la scelta più produttiva.

I problemi emergono quando si usa EF Core per tutto senza misurare.

Le query generate automaticamente non sono sempre ottimali.

Il change tracker ha un costo.

Il caricamento eager con Include può generare join pesanti dove una query separata sarebbe più efficiente.

Dapper entra in gioco per le query complesse dove serve controllo totale sull'SQL: report con aggregazioni complesse, query su viste materializzate, operazioni bulk, stored procedure legacy.

Non sostituisce EF Core: lo affianca nei casi specifici dove il controllo dell'SQL è più importante della produttività del mapping automatico.

Il pattern che uso più spesso è EF Core per write e operazioni transazionali, Dapper o query SQL dirette per read complesse e report.

Non è un'architettura sofisticata: è pragmatismo applicato.

Query efficienti in EF Core: le insidie da conoscere

Il problema N+1 è la trappola più comune con EF Core: per ogni elemento di una lista si esegue una query aggiuntiva invece di un join.

Si manifesta quando si itera su una collection e si accede a navigation property non caricate, e può trasformare una lista di cento elementi in centocento query al database.

La soluzione è il caricamento esplicito con Include() per le navigation property necessarie, oppure la proiezione con Select() per caricare solo i campi necessari senza navigare l'intero oggetto.

La proiezione è spesso la scelta migliore per le query di lettura: genera SQL più semplice, carica meno dati e non attiva il change tracker.

AsNoTracking() è un altro strumento fondamentale per le query di sola lettura: disabilita il change tracking e riduce l'allocazione di memoria.

Su query che restituiscono centinaia di oggetti, la differenza è misurabile.

Lo strumento per diagnosticare i problemi è EnableDetailedErrors() e il logging delle query SQL generato da EF Core.

In sviluppo, vedere l'SQL generato è indispensabile.

In produzione, Application Insights o il query store di SQL Server rivelano le query lente prima che diventino incidenti.

Migrazioni e schema evolution: come non avere paura del database

Le migrazioni EF Core sono uno degli strumenti più sottovalutati dell'ecosistema.

Permettono di versionare lo schema del database insieme al codice, di applicare modifiche in modo ripetibile e di rollback quando necessario.

Le insidie delle migrazioni vengono quasi sempre da migrazioni troppo grandi o distruttive applicate senza piano.

Rinominare una colonna in una singola migrazione genera una DROP e una ADD, non un RENAME: tutti i dati di quella colonna vanno persi se non si gestisce esplicitamente la trasformazione.

Le migrazioni che modificano dati esistenti devono essere testate su una copia del database di produzione prima dell'applicazione.

Il pattern che riduce il rischio è la migrazione in due fasi per i cambiamenti breaking: prima si aggiunge la nuova struttura mantenendo quella vecchia, si migra il codice a usare la nuova struttura, poi in una release successiva si rimuove quella vecchia.

Più lento, molto più sicuro.

In produzione le migrazioni non dovrebbero mai girare automaticamente all'avvio dell'applicazione.

Devono essere script SQL revisionati, applicati in modo controllato e registrati come parte del processo di deploy.