Utilizziamo i cookie per analisi, contenuti personalizzati e pubblicità.

Queste informazioni possono essere condivise con i nostri partner per fornire i servizi necessari.

Approfondisci

AccettoRifiuto

Dall'archivio articoli > LINQ

Migliorare le performance di accesso ai dati con Entity Framework 4.0 e 4.1

di Stefano MostardaStefano Mostarda, in LINQ,

Quando sviluppiamo un'applicazione, l'accesso ai dati è una delle parti cruciali per quanto riguarda le performance del sistema. Quando usiamo ADO.NET, abbiamo pieno controllo sull'accesso ai dati, in quanto siamo noi a scrivere il codice SQL che viene inviato al database e siamo noi ad eseguire esplicitamente ogni singola query: quindi, possiamo tenere sott'occhio le performance in maniera semplice.

Ora che il .NET Framework ha permesso la diffusione della programmazione a oggetti, e quindi l'adozione di un Object Model o di un Domain Model (nel proseguo dell'articolo ci riferiremo a entrambi come modello) nelle nostre applicazioni, è cambiato il modo in cui lavoriamo con i dati presenti nel database. Lo strato software che si occupa di lavorare con il database non restituisce più dati tabulari nel formato del database, ma restituisce oggetti (che contengono dati) nel formato del nostro modello (che ha un formato che rispecchia il business e non la struttura dei dati nel DB). Quando dobbiamo aggiornare i dati, li aggiorniamo nel modello e poi chiediamo allo strato che colloquia con il database di persistere questi dati nel database.

Scrivere il codice per eseguire queste operazioni è molto complicato ed è per questo motivo che sono nati gli O/RM. Un O/RM garantisce la possibilità di lavorare con il nostro modello e delegare all'O/RM la persistenza dei dati sul database mascherando al nostro codice tutto il colloquio con il database.

Se da un lato avere un O/RM ci permette di risparmiare codice, dall'altro ci fa perdere il controllo completo sul codice SQL che viene usato. Inoltre, ci vengono mascherate le query che vengono realmente eseguite in quanto noi ci preoccupiamo di recuperare e persistere dati senza sapere nulla di come poi l'O/RM li gestirà sul database. Infine, l'O/RM è uno strato software aggiuntivo (anche molto complesso) e inevitabilmente rallenta le prestazioni della nostra applicazione rispetto all'accesso diretto ai dati effettuato con ADO.NET (su cui l'O/RM si basa).

In questo articolo, vedremo quali sono le performance di Entity Framework (l'O/RM di casa Microsoft) e cosa possiamo fare per ottimizzarle al massimo.

Definizione dell'ambiente

Per effettuare questo test è stata utilizzata una macchina con le seguenti caratteristiche:

  • processore 2.3GHZ
  • 8gb RAM
  • SSD
  • Windows 7 64Bit
  • SQL Server 2008 R2
  • Il database contiene 70 tabelle
  • La tabella su cui sono effettuate le query contiene 100 record

I numeri che vedremo in questo articolo hanno valore relativo e non assoluto. Su macchine più o meno potenti i numeri sono diversi; quello che rimane inalterato è il tasso di velocizzazione delle prestazioni una volta applicate le tecniche che vedremo nell'articolo.

Il primo test

Il primo test che eseguiamo verifica le prestazioni di Entity Framework nell'ambiente di default. Per fare questo, importiamo la tabella MyTable nel designer (MyTable è la sola tabella popolata). Una volta importata la tabella recuperiamo tutti i record da questa tramite il seguente codice:

Stopwatch sw = new Stopwatch();
sw.Start();

for (var i = 0; i < 50; i++)
{
  using (var ctx = new PerformanceEFEntities())
  {
    ctx.MyTables.ToList();
  }
  if (i==0)
    Console.WriteLine("FirstExecution: " + sw.Elapsed.TotalMilliseconds);
}
sw.Stop();
Console.WriteLine("Total Execution: " + sw.Elapsed.TotalMilliseconds);
Console.WriteLine("Average: " + sw.Elapsed.TotalMilliseconds / 50);
Console.ReadLine();

Il codice appena mostrato recupera tutti dati nella tabella MyTable per 50 volte ed inoltre scrive sulla console il tempo di esecuzione della prima query, il tempo totale di esecuzione ed il tempo medio di esecuzione. Il risultato che si ottiene dall'esecuzione questo codice è il seguente:

Ora che abbiamo un'idea di quelle che sono le prestazioni di base, vediamo come introducendo alcuni trucchi possiamo ottimizzare le prestazioni.

3 pagine in totale: 1 2 3
Contenuti dell'articolo

Commenti

Visualizza/aggiungi commenti

| Condividi su: Twitter, Facebook, LinkedIn
Aggiorna

Per inserire un commento, devi avere un account.

Fai il login e torna a questa pagina, oppure registrati alla nostra community.

Approfondimenti

Top Ten Articoli

Articoli via e-mail

Iscriviti alla nostra newsletter nuoviarticoli per ricevere via e-mail le notifiche!

In primo piano

.NET Conference Italia 2024 - Milano

.NET Conference Italia 2023 - Milano e Online

Le novità di .NET 7 e C# 11

Le novità in ASP.NET Core e Blazor con .NET 7

I più letti di oggi

In evidenza

Misc