EntityFramework 5 filtert eine enthaltene Navigationseigenschaft

Ich möchte eine Möglichkeit finden, Linq zum Filtern einer Navigationseigenschaft nach einer Untermenge verwandter Entitäten zu verwenden. Ich weiß, dass alle Antworten zu diesem Thema die Verwendung eines anonymen Selektors vorschlagen, z.

query.Where(x => x.Users.Any(y => y.ID == actingUser.ID)) .Select(x => new { Event = x, Discussions = x.Discussions.Where(actingUser.GenerateSecurityFilterFor()) }) .OrderBy(x => x.Discussions.Count()) .ThenBy(x => x.Event.Name); 

Dies ist jedoch aufgrund der generellen Natur unserer Abfrageerzeugung deutlich weniger als ideal und führt auch zu äußerst abschreckenden SQL-Abfragen, wenn Sie den Profiler hochcasting.

Ich möchte etwas erreichen können wie:

 query.Include(x => x.Discussions.Where(actingUser.GenerateSecurityFilterFor())) .OrderBy(x => x.Discussions.Count()) .ThenBy(x => x.Name); 

Ich stelle fest, dass dies in EF5 nicht unterstützt wird (oder in einer anderen Version für diese Angelegenheit), aber es muss eine Möglichkeit geben, die Ergebnismenge durch Linq zu beschränken, ohne in anonyme Typanweisungen zu gehen.

Ich habe versucht, etwas zu tun:

 query.GroupJoin(discquqery, x => x.ID, x => x.Event.ID, (evt, disc) => evt.Discussions = disc.Where(actingUser.GenerateSecurityFilterFor())).ToList(); 

Sie können jedoch keine Zuweisung in einem Lambda-Ausdruck haben. Wenn Sie hier einen anonymen Typ auswählen, wird dasselbe Dilemma wie bei der Auswahl von select erzeugt.

Ich schätze, ich kann nicht verstehen, warum EF keine Möglichkeit bietet (die ich finden kann):

 SELECT --Properties FROM Event e LEFT OUTER JOIN Discussions d ON e.ID = d.EventID AND --Additional constraints WHERE --Where conditions ORDER BY --Order Conditions 

Es ist so einfach, den Join in SQL zu beschränken, da es HAS eine Möglichkeit gibt, dies auch über Linq zu tun.

PS: Ich habe Stack, MSDN, Expert-Exchange usw. gesucht. Bitte beachten Sie, dass dies kein Duplikat ist. Alles, was auch nur zu diesem Thema führt, hat entweder die Antwort “Es kann nicht gemacht werden” oder gar keine Antwort. Nichts ist unmöglich … einschließlich dieses.

Alles, was auch nur zu diesem Thema führt, hat entweder die Antwort “Es kann nicht gemacht werden” oder gar keine Antwort. Nichts ist unmöglich … einschließlich dieses.

Sicher. Es ist möglich. Sie können EF-Quellcode herunterladen und diese function selbst hinzufügen. Dies wird ein großer Beitrag zum Open Source-Projekt und zur Community sein. Ich glaube, das EF-Team wird Ihnen gerne bei Ihren Bemühungen helfen.

Mit der aktuellen Version “Es geht nicht” ist die Antwort . Sie können Projektion entweder für einen anonymen oder speziellen nicht zugeordneten Typ verwenden, wie Sie zu Beginn Ihrer Frage beschrieben haben. Andere Optionen sind separate explizite Abfragen zum Laden verwandter Entitäten für einzelne übergeordnete oder separate Abfragen zum Laden verwandter Entitäten für alle übergeordneten Elemente.

Lastbeziehungen für Alleinerziehende:

 context.Entry(event) .Collection(e => e.Discussions) .Query() .Where(d => ...) .Load(); 

Ladebeziehungen für alle Eltern (das Lazy Loading muss deaktiviert sein):

 // load all parents var events = query.Where(e => ...).ToList(); // load child filtered by same condition for parents and new condition for children childQuery.Where(d => e.Event ... && d.Something ...).Load(); 

Die zweite Lösung erfordert, dass child die Navigationseigenschaft zurück zum übergeordneten Objekt hat (um dieselbe Abfragebedingung zu erstellen, die anfänglich zum Laden des übergeordneten Elements verwendet wurde). Wenn Sie alles korrekt konfiguriert haben und Entitäten angehängt sind, sollte EF Ihre Beziehungen (Sammlungen) in übergeordneten Entitäten automatisch korrigieren (die Sammlung wird jedoch im dynamischen Proxy nicht als geladen markiert. Aus diesem Grund können Sie diese Option nicht zusammen mit dem verzögerten Laden verwenden).