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?
C'è qualche differenza nel piano di query tra i due? – Laurence
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. –
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