È più veloce eseguire query utilizzando linq-to-entities o un adattatore dati?

In generale, ADO.NET (OracleConnection, OracleCommand, ecc.) sarà più veloce.

Tuttavia, nei casi in cui la query LINQ viene tradotta direttamente in una singola query SQL, la differenza di velocità dovrebbe essere piuttosto ridotta. C'è una certa quantità di logica wrapper aggiuntiva che deve ancora essere applicata (e, sei in balia della logica di traduzione), ma nello schema generale delle cose la differenza di velocità è solitamente piuttosto insignificante.

Il vero rallentamento si verifica quando fai qualcosa nella tua query LINQ che impedisce l'esecuzione come una singola query SQL, ad es. invocando ".ToList ()" su una delle raccolte che si stanno unendo nella tua clausola "da". Unirsi a qualcosa che non è una tabella di database avrebbe anche questo effetto, ma non è proprio un confronto equo; ADO.NET non può nemmeno eseguire quel tipo di query (almeno, non come una query di per sé).

Nella mia esperienza, si può dire se una query LINQ viene direttamente tradotta in una query SQL cercando di ottenere l'SQL effettivo durante una sessione di debug del runtime. Se è lì (ad es. Quando passi con il mouse su una variabile in cui è caricata la query), va bene.

Provalo e guarda!

Una cosa da notare è che se si usa Linq e non si include una clausola .Select, si eseguirà (in modo efficace) "select *" dal DB, che sarà più lento e meno efficiente.

Quando ho usato Oracle per l'ultima volta con Linq, ha generato SQL particolarmente sgradevole, eseguendo molte pagine. Penso che il provider sia stato aggiornato da allora. È possibile attivare la registrazione e vedere quale SQL viene eseguito quando viene eseguita la query LINQ e osservare il piano di esecuzione per vedere la differenza tra quella e la query codificata a mano.

Naturalmente, puoi fare il meglio di entrambi i mondi: scrivi le tue domande a mano e esponile come stored procedure. Quindi usa Linq per accedervi, la query veloce ed efficiente verrà eseguita anche se la chiami da LINQ.