Fordert Dapper vor den Linq-Operationen ein vollständiges Objekt von der Datenbank an?

Question

Ich war eine Weile neugierig darauf, wie Dapper (oder vielleicht andere ORMs) den Objektabruf in Verbindung mit LINQ handhabt.

Wenn ich eine Klasse wie folgt:

public static IEnumerable<SitePage> GetAll() 
{ 
    using (IDbConnection cn = new SqlConnection(g.Global.CONX)) 
    { 
     cn.Open(); 
     return cn.GetAll<SitePage>(); 
    } 
} 

und ich eine Abfrage wie folgt konstruieren:

var result = SitePage.GetAll().Select(c=> new { c.id, c.PageUrl, c.ParentId }); 

Ich bin neugierig, wenn im Hintergrund, der gesamte Datensatz in darunter gezogen wird alle anderen Spalten (die wirklich große varchars enthalten können), oder versteht Dapper von dieser Abfrage nur, um die Spalten einzuholen, die ich von der sql db anfordere? Ich weiß, es ist eine Art Neuling, aber ich möchte die Dapper/LINQ-Interaktion besser verstehen. Eine ähnliche Frage wurde hier gepostet: selecting-specific-columns-using-linq-what-gets-transferred, obwohl ich nicht sicher war, ob vollständig beantwortet wurde. Das Poster hatte 2 Fragen und verwendete auch keine Lambda-Ausdrücke, die ich generell bevorzuge.

Die Antwort darauf wird meine Meinung in Brand setzen (und möglicherweise ändern Sie die Art, wie ich kodiere, wie ich vorsichtig war und fühle, dass ich über explizite SQL zu viel Code schreibe).

Answer 1

Dapper wandelt Ihre Lambda-Ausdrücke nicht in SQL um. In diesem Fall gibt die von Dapper generierte SQL-Abfrage die vollständigen Instanzen von SitePage zurück.

Ein schneller Weg zu wissen, ob das der Fall ist, wenn Sie sich die Signatur von Dappers GetAll<T> Methode anschauen. Da es IEnumerable<T> zurückgibt, bedeutet dies, dass es eine Sammlung von T zurückgibt, also wird jeder Operator, den Sie danach verwenden - wie Select in Ihrem Fall - auf die gesamte Sammlung angewendet. Kurz gesagt, Sie sind nicht mehr in Dapper Welt nach dem Anruf GetAll<T>.

Wenn Sie in der Vergangenheit vollwertige ORMs - also mit mehr Funktionen, nicht unbedingt besser - wie Entity Framework oder NHibernate verwendet haben, werden Sie feststellen, dass einige APIs IQueryable<T> zurückgeben, was eine Abfrage darstellt, die nicht funktioniert noch ausgeführt worden. So ändern die Operatoren, die Sie an einem IQueryable<T> wie Select und Where verwenden, die Abfrage tatsächlich. Wenn Sie die Abfrage materialisieren, indem Sie sie iterieren oder ToList oder ToArray darauf aufrufen, transformiert der ORM Ihren Abfrageausdrucksbaum in SQL und sendet diese Abfrage an die Datenbank.