2013-10-05 12 views
7

Non riesco a capire perché l'output SQL ha una sottoquery per una query semplice che ho scritto in LINQ. Questo è il mio codice:LINQ generazione di query secondarie per un semplice ordine tramite

var list = db.User.Where(u => u.Name == somename).OrderBy(u => u.IdUser).ToList(); 

dove nomeacaso è un parametro che sto passando al momento dell'esecuzione.

L'SQL uscita è:

SELECT 
Project1.IdUser, 
Project1.Name 
FROM (SELECT 
Extent1.IdUser, 
Extent1.Name 
FROM user AS Extent1 
WHERE Extent1.Name = 'John' /* @p__linq__0 */) AS Project1 
ORDER BY 
Project1.IdUser ASC 

Qualora l'uscita davvero un sub-query per qualcosa di così semplice?

Ho anche provato

var list = db.User.Where(u => u.Name.Equals(somename)).OrderBy(u => u.IdUser).ToList(); 

che genera la stessa uscita come sopra.

Se codificare il parametro, come:

var list = db.User.Where(u => u.Name == "John").OrderBy(u => u.IdUser).ToList(); 

Esso funziona come previsto, generando solo

SELECT 
Extent1.IdUser, 
Extent1.Name 
FROM user AS Extent1 
WHERE 'John' /* @gp1 */ = Extent1.Name 
ORDER BY 
Extent1.IdUser ASC 

Un paio di cose che sto usando:

  • EntityFramework 5 , .NET 4.5
  • SQL Server 2012
  • Glimpse (che utilizza MiniProfiler) per vedere il codice SQL generato

Io non sono un esperto di LINQ, così che cosa mi manca qui?

+2

C'è qualche differenza nel piano di query tra i due? – Laurence

+0

No, si risolvono nello stesso piano di esecuzione, ma questa sintassi mi infastidisce. Immagina se sto eseguendo il debug di una query più complessa generata da LINQ con tutta questa inutile complessità, non sarebbe produttivo. –

+0

L'astrazione ha un costo. Se non ti piace il costo, scrivi tu stesso l'SQL. Non c'è il lato giusto o sbagliato da queste scelte. – Laurence

risposta

2

Come indicato in altri punti, la query restituisce lo stesso piano di esecuzione del tuo. Entity Framework (e LINQ to Entites) è qui per aiutarti a evitare di scrivere SQL e preoccuparti di SQL (in una certa misura). In circostanze normali non ti interessa che SQL venga generato, né lo "fai da debug". Ti interessa solo se la query LINQ è corretta. Entity Framework (dovrebbe) lo traduce in SQL corretto (talvolta persino previsto) (e ancora, il piano di esecuzione è importante).

Non sto dicendo che non si dovrebbe guardare a SQL per motivi di prestazioni (o meglio per dire piano di esecuzione di quella query). Ma questo dovrebbe essere fatto dopo che hai identificato problemi di prestazioni. E per prima cosa dovresti provare a scrivere semplice, questa è la via del successo. Naturalmente se conosci SQL sai che questo mondo di insiemi è diverso dal mondo dell'oggetto - puoi scrivere facilmente una query abbastanza media in LINQ (grazie al mondo degli oggetti), ma questo finirà per essere un brutto SQL (imposta il mondo) a causa di " disallineamento "tra mondi.