Eager Läden verbundenen Unternehmen in EF-Core mit EF6 Syntax

Question

In EF6 verwenden wir wie diese verbundenen Unternehmen zu laden:

query             // (A) 
    .Include(q => q.Employee.Supervisor.Office.Address) 
    .Include(q => q.Orders); 

Das würde eifrig Last aller Entitäten in dieser Kette.

In EF-Core, sollen Sie, dies tun: (! Viel)

query             // (B) 
    .Include(q => q.Employee) 
    .ThenInclude(q => q.Supervisor) 
     .ThenInclude(q => q.Office) 
     .ThenInclude(q => q.Address) 
    .Include(q => q.Orders); 

, die viel weniger freundlich, aber funktioniert.

Unsere Codebasis hat Tonnen von (A) Anrufe, die wir auf (B) aktualisieren müssen, damit wir EF Core verwenden können.

Ich habe festgestellt, dass EF Core in vielen Fällen perfekt mit (A) funktioniert, obwohl es nicht sollte! ... und manchmal scheitert es vollständig.

Ist das ein Zufall? Soll es unter bestimmten Umständen mit (A) arbeiten? Denn wenn ich es nicht muss, habe ich keine Lust, viele hundert Änderungen vorzunehmen und sie dann zu testen.

Answer 1

Tatsächlich funktionieren beide Syntax in EF Core, sofern der Include-Pfad einfache Referenztypen (d. H. Nicht Sammlungstyp) Navigationseigenschaften enthält. Es ist, weil die „fließend“ -Version von Include sowohl EF6 und EF Core ist eine Art sichere Art und Weise zu beschreiben, einen Navigations Eigenschaft Pfad wie Root Modellierung ->Employee ->Supervisor ->Office ->Address, die unsichere Version als string dargestellt wird (auch unterstützt von EF6 und EF Core) "Employee.Supervisor.Office.Address". EF Core-Beispiele scheinen immer das Include/ThenInclude-Muster zu verwenden, da es universeller ist und sowohl für Referenz- als auch für Sammlungstypeigenschaften gut funktioniert, wie wir später sehen werden.

Der wirkliche Unterschied kommt bei der Beschreibung verwandter Eigenschaften eines Sammlungstyps Navigationseigenschaften. Nehmen wir an, die Order Klasse aus Ihrem Beispiel hat eine Navigationseigenschaft ICollction<OrderDetail> OrderDetails und OrderDetail Klasse enthält Vendor Vendor Eigenschaft. Der string Navigationspfad zum Einschließen von Stamm + Bestellungen + Bestelldetails + Bestelldetailverkäufer ist "Orders.OrderDetails.Vendor", aber er kann nicht einfach als Include(q => q.Orders.OrderDetails.Vendor) Ausdruck dargestellt werden (Kompilierungsfehler). Hier verfolgen EF6 und EF Core einen anderen Ansatz. EF6 aufgelöst wird es Standard-LINQ Select Operator:

.Include(q => q.Orders.Select(o => o.OrderDetails.Select(d => d.Vendor))) 

und EF-Kern - mit ThenInclude benutzerdefinierte Erweiterung Methode:

.Include(q => q.Orders).ThenInclude(o => o.OrderDetails).ThenInclude(d => d.Vendor) 

kann ich nicht sagen, welches besser ist - beide haben eine Vor-und Nachteile . EF6 erzeugt eine Verschachtelung, ermöglicht jedoch, dass externer Code Include-Ausdrücke (der Form Expression<Func<T, object>>) bereitstellt, ohne auf die EF-bezogenen Assemblies zu verweisen. Auf der anderen Seite ist die EF Core-Syntax "flach" und ermöglicht die einfache Verkettung zusätzlicher Eigenschaften, die keine Sammlung oder Referenz enthalten, aber es gibt keine einfache Möglichkeit, Includes extern bereitzustellen.

Aber der Hauptpunkt ist - besser oder nicht, die Syntax zum Einbeziehen einer Sammlung Element-bezogenen Eigenschaft ist anders und muss berücksichtigt werden, wenn EF6-Code EF Core zu portieren. Tatsächlich wurde in einigen anfänglichen EF Core-Versionen die alte Syntax unterstützt (zusätzlich zur neuen Syntax), aber aus irgendeinem unbekannten Grund wurde sie entfernt.Die einzige gute Sache ist, dass Sie nicht alle Ihre Include s ändern müssen - nur diejenigen mit Select innerhalb finden und sie in ThenInclude Syntax konvertieren.