LINQ che genera sottorequery per un semplice ordine di

Ho difficoltà a capire perché l’output SQL abbia una sottoquery per una semplice query che ho scritto in LINQ. Questo è il mio codice:

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

dove somename è un parametro che sto passando al momento dell’esecuzione.

L’output SQL è:

 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 

L’output dovrebbe davvero avere una sottoquery 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 lo stesso risultato di cui sopra.

Se codice il parametro, come:

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

Funziona come previsto, generando solo

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

Alcune cose che sto usando:

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

Non sono un esperto di LINQ, quindi cosa mi manca qui?

Come indicato in altri punti, la query produce 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 dovrebbe essere fatto dopo aver identificato i problemi di prestazioni. E dovresti provare a scrivere le domande in modo semplice , questa è la via del successo. Naturalmente se conosci SQL sai che questo mondo di insiemi è diverso dal mondo dell’object – 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.