Ottimizzare le performance di un'applicazione che utilizza Entity Framework

Ottimizzare le operazioni di aggiornamento

L'utilizzo di stored procedure nella fase di lettura dei dati non è l'unico caso in cui queste portano benefici alle performance. Anche la fase di scrittura può essere ottimizzata. Si supponga di dover loggare in una tabella non gestita da Entity Framework ogni qualvolta venga fatta un'operazione su un veicolo.

Una buona idea potrebbe essere quella di lanciare una stored procedure subito dopo aver chiamato il metodo SaveChanges mettendo il tutto in una transazione tramite la classe TransactionScope. Sebbene il codice funzioni e sia anche molto pulito, un approccio del genere comporta automaticamente l'utilizzo del MSDTC che ha lo sconveniente di rallentare la gestione della transazione. Inoltre, in questo modo si esegue un roundtrip verso il database per effettuare il log. Se da un lato questa è una cosa normale, dall'altro può comunque essere evitata.

L'approccio migliore consiste nell'utilizzare le stored procedure per eseguire gli aggiornamenti delle tabelle dei veicoli ed inserire all'interno di queste il codice necessario a loggare i dati. In questo modo si eliminano entrambi gli svantaggi visti in precedenza in quanto la transazione rimane unica e gestita da Entity Framework ed il roundtrip aggiuntivo verso il database viene eliminato in quanto l'insert nella tabella di logging viene eseguita nelle stored procedure di aggiornamento dei veicoli.

Anche l'utilizzo di stored procedure per aggiornare i dati è stato affrontato nello stesso precedente articolo e quindi si rimanda a questo per approfondimenti su questa tecnica.

Ottimizzare il trattamento dei dati

Molto spesso capita di dover visualizzare i dati in una griglia in sola visualizzazione e nel modo più veloce possibile. Quando si esegue questo tipo di operazioni, spesso la trasformazione dei dati in oggetti risulta dannosa per le performance. Infatti, grazie alla grande potenza dei meccanismi di databinding, avere un oggetto o una struttura generica non fa alcuna differenza.

In questo caso si può ricorrere al linguaggio di interrogazione Entity SQL in combinazione sia con l'ObjectContext che con l'Entity Client Data Provider. Inoltre, in casi di estrema necessità di performance, si può anche saltare a piè pari tutto lo strato di querying di Entity Framework ed accedere in maniera diretta al database sempre però sfruttando le sue classi.

Prendiamo in esame il primo caso ovvero l'utilizzo di Entity SQL in combinazione con la classe ObjectContext. In questo caso si utilizza il metodo CreateQuery passando in input la query Entity SQL.

var result = ctx.CreateQuery<DbDataRecord>("SELECT v.name " + 
  "FROM SPEFEntities.Vehicle as v").Execute(MergeOption.AppendOnly);

Questa query estrae il nome di tutti i veicoli nel database e li mette in una lista di oggetti generici di tipo DbDatarecord. A questo punto collegare la query ad una griglia è estremamente semplice in quanto basta assegnare la variabile result alla proprietà datasource della griglia e poi, in caso di griglia web, invocare il binding.

L'utilizzo del metodo Execute per eseguire la query è molto performante ed è da preferire agli altri metodi utilizzati per scatenarne l'esecuzione. Infatti, i metodi ToArray e ToList non fanno altro che trasformare il risultato rispettivamente in DbDataRecord[] e in List<DbDataRecord>. Lo sconveniente di questi metodi è che la trasformazione è molto lenta. Per dare un'unità di misura, su una tabella di 44000 record utilizzare il metodo Execute impiega 3 millesimi di secondo, mentre il metodo ToList ne impiega 140 e ToArray circa 70.

Il passaggio per il metodo CreateQuery non è obbligatorio quando si usa Entity SQL come linguaggio di interrogazione. Infatti, si può sfruttare lo strato dell'Entity Client Data Provider per ritrovare i dati ad un livello ancora più basso. L'accesso all'Entity Client può essere fatto sia sfruttando direttamente le sue classi, oppure attraverso l'ObjectContext.

Nel primo caso, si devono sfruttare le classi EntityConnection, EntityCommand ed EntityDataReader. Come si può faclmente immaginare dal loro nome, queste classi ereditano dalle classi base di ogni provider ADO.NET e quindi il loro uso rimane lo stesso.

using (var conn = new EntityConnection("name=connstring")){ 
  using (var comm = new EntityCommand( 
        "SELECT v.name FROM SPEFEntities.Vehicle as v")){ 
    con.Open(); 
    var reader = comm.ExecuteReader(CommandBehavior.SequentialAccess); 
  } 
}

L'utilizzo del parametro CommandBehavior.SequentialAccess è obbligatorio e fondamentale proprio per questioni di ottimizzazione. Questo parametro prevede che le colonne siano accedute in maniera sequenziale ottimizzando così l'utilizzo della memoria.

Questa tecnica è in assoluto la migliore in termini di performance in quanto alla velocità del datareader si associa anche quest'ultima ottimizzazione nell'accesso alle colonne.

Nel caso in cui si decida di utilizzare l'ObjectContext come punto di entrata allo strato dell'Entity Client, si può utilizzare la proprietà Connection e poi comunque ricreare gli oggetti come nell'esempio precedente.

using (var ctx = new DBContext()) { 
  using (EntityCommand comm = new EntityCommand( 
    "SELECT v.name FROM SPEFEntities.Vehicle as v",  
    (EntityConnection)ctx.Connection)) { 
    ctx.Connection.Open(); 
    var reader = comm.ExecuteReader(CommandBehavior.SequentialAccess); 
  } 
}

In realtà, quest'approccio non offre alcun vantaggio rispetto all'esempio precedente che e quindi è preferibile soprattutto perché offre una miglior leggibilità visto che segue il pattern usato quando si utilizza un qualunque altro provider per ADO.NET.

Sullo stesso argomento

Commenti

Per inserire un commento, devi avere un account.

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

Segnala su: