Dieser Artikel wurde maschinell übersetzt.

Datenpunkte

Die Enträtselung der Entity Framework-Strategien, Teil 3: Klassen, Abfragen und Kontexte

Julie Lerman

Dies ist das dritte in einer Reihe von Datenpunkten Spalten die helfen Sie einige wichtigen Entscheidungen zu treffen, wenn Sie das Entity Framework als Ihre Datenzugriffsebene in Ihren Anwendungen verwenden. Die erste, zum Modell-Erstellung-Workflow in der Ausgabe Mai 2011 (bit.ly/lOcjPz), diskutierten zwischen der ersten Code, Modell erste und Datenbank erste Workflows wählen. Code zunächst nicht mithilfe eines visual-Modell, aber Datenbank erste und Modell erste tun. Eine gezielten Auswahl treffen in diesem Artikel konzentrieren sich auf den Code Generation Optionen, wenn Sie ein visual-Modell haben, von dem Sie Ihre Domäne Klassen erstellen werden. Während auf das Thema der Codegenerierung, nehme ich einen kurzen Blick auf auswählen zwischen der Verwendung der ObjectContext und DbContext und die Wahl zwischen LINQ to Entities als auch Entity SQL.

Generierten Klassen: EntityObjects oder POCOs?

Die erste Version von Entity Framework (EF nachstehend für Kürze) stützten sich auf der EntityObject-Klasse aktivieren Sie Entitäten für die Interaktion mit den ObjectContext, wie es Beziehungen und Überarbeitungen Entitätsinstanzen verwaltet. Die Codegenerierung sichergestellt, dass die von Ihr Modell generierten Klassen von EntityObject geerbt. Dies ist immer noch der Standard mit Visual Studio 2010, aber jetzt haben Sie eine andere Option. In der Microsoft.NET Framework 4, der EF und seine ObjectContext gewonnen, die Fähigkeit, Änderungen nachverfolgen und Verwalten von Beziehungen zwischen Entitäten ohne abhängig von der EntityObject zum Senden von Benachrichtigungen dem ObjectContext. Das bedeutet, dass Ihre Klassen nicht mehr zum Erben von EntityObject, die macht einen großen Unterschied für Entwickler, die Persistenzignoranz, Trennung von Bedenken, Komponententests und andere Software-Praktiken, die unter dem generalisierten Dach der agilen Entwicklung fallen interessiert sind.

Klassen, die nicht auf andere APIs werden als Plain Old CLR Objects oder POCOs bezeichnet. Die EF-Fähigkeit, diese saubereren Klassen verwenden aber noch die Änderungsnachverfolgung und anderen Entität-Verwaltungsaufgaben ausführen bezeichnet man als die "POCO Unterstützung." Diese Unterstützung bietet das Rückgrat für Code ersten. Da die EF mit POCO Entitäten arbeiten kann, können Klassen, die Sie im Code ersten Szenario erstellen auch durch den EF-Kontext verwaltet werden.

Also wenn die EF der EntityObject-Benachrichtigung Zusammenhang mit Änderungen an den Entitäten verwendet, wie ist es möglich, POCOs zu haben, die nicht nur nicht von EntityObject erben, sondern keine Kenntnis von der EF haben? Die EF arbeitet mit zwei Pfade, damit Entwickler haben ihre sprichwörtliche Kuchen und ihn auch essen. Eine Sache, die nicht ändert, ist, dass der ObjectContext muss noch werden bewusst, welche Klassen für verantwortlich ist.

Der erste Pfad zur POCO Unterstützung ergibt sich aus den ObjectContext immer noch schlauer als der der.NET Framework 4. Jetzt ist der Kontext in der Lage, die Klassen überprüfen, die sie verwalten ist. Es verfügt über neue Methoden wie z. B. DetectChanges, die liest die Objekte, die sie zur Verwaltung und aktualisieren Sie dann die Zustandsinformationen, die es für diese Objekte nachverfolgt.

Die zweite Art und Weise die EF kann verwenden Sie POCOs, während noch in den Genuss Rahmen ein bisschen Trickserei in Form von Proxy-Objekte verwendet. Wenn jedes einer der POCO-Klasseneigenschaften virtueller markiert ist, wird von der EF-Laufzeit einen Proxy (Wrapper) um das Objekt erstellt und diesen Proxy tut dieselbe Aufgabe wie mit der EntityObject. Die Proxyklasse wird Kontext-Eigenschaft und Beziehung Änderungen benachrichtigen. Sie können auch die Proxies nutzen, ohne Auswirkungen auf die gesamte Klasse. Die EF werden faul Last Navigationseigenschaften, die virtuelle, gekennzeichnet sind, selbst wenn die anderen Eigenschaften nicht sind.

Abbildung 1 zeigt eine visuelle Darstellung der drei Wege jetzt erhältlich für den ObjectContext zu verfolgen Änderungen der Entität, mit EntityObjects oder eine der zwei POCO-Mechanismen.

Abbildung 1 wie Entity Framework Tracks ändert in Entitäten

ObjectContext oder DbContext?

Die EF-4.1 eingeführt, eine vereinfachte Version der ObjectContext aufgerufen DbContext. Es bietet alle die gleiche POCO Unterstützung als der ObjectContext. DbContext schließt auch einige komplexere Logik erforderlich für die Codierung gegen den ObjectContext in einfachere Methoden und Eigenschaften, erleichtert die gebräuchlichsten Codieraufgaben in der EF ausführen.

Die DbContext ist der Standardkontext verwenden Sie mit Code ersten Klassen, aber der ObjectContext wird standardmäßig mit Datenbank-erste und Modell erste. Microsoft bietet Alternativen Code-Vorlagen für die letzteren beiden Modelle. Die erste ist die ADO.NET POCO Entity Generator. Dadurch POCO Klassen zusammen mit einem ObjectContext-Klasse für deren Verwaltung. Die zweite Teil der EF-4.1-Installation ist die ADO.NET-DbContext-Generator. Dadurch wird auch POCO Klassen erstellt. Aber die Kontextklasse, die zum Verwalten der Klassen generiert wird, die von DbContext erbt. Also welcher Workflow beginnen Sie mit — Code ersten, Modell erste oder Datenbank erste – Sie haben die Möglichkeit, die DbContext verwenden, wenn es das ist Ihre Präferenz. Die DbContext hat ein Fenster in der ObjectContext, so dass Sie dort bekommen können, falls erforderlich.

Abfrage-Optionen: LINQ to Entities- oder Entity SQL

Eine andere große Frage haben Entwickler über die EF ist, wenn sie LINQ to Entities- oder Entity SQL zum Schreiben und Ausführen von Abfragen verwenden soll. Sie auch Fragen, warum die beiden vorhanden sind. Entity SQL wurde neben dem Entitätsdatenmodell als seine systemeigene Abfragesyntax gebaut. LINQ ist eine Erweiterung von c# und Visual Basic und entstand durch die Sprachen-Teams. Wenn die Datenplattform-Gruppe über die Arbeit auf LINQ gelernt, wusste sie, dass es wäre eine natürliche Erweiterung auf die Abfragen Bedürfnisse in der EF, so dass sie die LINQ to Entities-Implementierung erstellt.

LINQ to Entities als Ihre Standard-Abfrage-Strategie

LINQ to Entities ist eine Implementierung von LINQ to Objects. LINQ können Sie Abfragen für stark typisierte Objekte, und im Fall von schreiben die EF, Sie können Abfragen schreiben, gegen Ihre Entitätsklassen. LINQ ist auf zweierlei Weise ausgedrückt. Die erste ist mit Operatoren. Die Abfrageanweisungen sehen ein wenig wie eine SQL-Anweisung. Die Abfrage erfordert eine Instanz eines EntityContainer, die von einem ObjectContext, hier genannt Kontext erbt:

IQueryable<Family> query =
  from f in context.Families where f.Pets.Any() select f;

Während Sie diesen Ausdruck eingeben, können Sie IntelliSense mit nicht nur den stark typisierten Klassen, sondern auch mit der LINQ-Syntax. Die Abfrage gibt ein IQueryable Familie-Typen. Die Abfrage muss noch ausgeführt werden, z. B. mit ToList:

List<Family> reptileFamilies = query.ToList();

Dadurch wird die EF zum Ausführen einer Abfrage in der Datenbank, schnappen Sie sich die Ergebnisse aus der Datenbank und erstellen Objekte mithilfe dieser Ergebnisse.

Die zweite Art, eine LINQ-Abfrage auszudrücken ist mit LINQ-Methoden. Diese erfordern Lambda-Ausdrücke als ihre Parameter. Ich werde die beiden vorherigen Anweisungen in einem einzigen LINQ-Abfrage komprimieren:

List<Family> reptileFamiles = 
  context.Families.Where(f=>f.Pets.Any()).ToList();

Da LINQ so einfach zu bedienen, ausdrückliche Abfragen ist – dank der starke Typisierung und IntelliSense — im Allgemeinen empfehle ich, dass Entwickler LINQ als ihre Standard-Abfrage-Strategie verwenden möchten. Sie können eine Vielzahl von Abfragen mit LINQ Ausdrücken. Darüber hinaus da LINQ viele Implementierungen verfügt, müssen bereits einen guten Griff auf es zu benutzen Sie. Wenn dies nicht der Fall ist, profitieren Sie höchstwahrscheinlich lernen LINQ to Entities und LINQ to Objects oder eine der vielen anderen Aromen von LINQ verwenden, um andere Codierung Probleme zu lösen. Außerdem finden Sie eine große viele Ressourcen für das Lernen, wie Sie mit LINQ Abfragen.

Entity SQL für Edge Case Abfragen und andere Sprachen

Entity SQL ist eine zeichenfolgenbasierte Abfragesyntax. Sie müssen um mit Entity SQL-Abfrage ausführen, verwenden eine ObjectQuery EF und der Entity SQL-Ausdruck übergeben. Wie sieht, die aus? Hier ist ein Beispiel:

string eSql = "SELECT VALUE f FROM PetsModelContainer.Families AS f";
ObjectQuery<Family> query = context.CreateQuery<Family>(eSql);
List<Family> families = query.ToList();

Wie die IQueryable, die Sie mit LINQ zu erstellen, muss dieser ObjectQuery noch ausführen, um die Ergebnisse aus der Datenbank abzurufen. ObjectQuery stellt eine alternative Möglichkeit zum Erstellen von Abfragen mithilfe von Methoden, die Ausschnitte von Entity SQL als ihre Parameter bereit.

Aber mit ein String-Ausdruck, es gibt keine starke Typisierung und, dass Abfrage-Ausdrucks nicht bis zur Laufzeit aufgelöst erhalten, sodass Sie Probleme bis dahin entdecken wird nicht. (Beachten Sie, dass Sie, die unverzichtbare LINQPad verwenden können — finden Sie unter linqpad.net— Entity SQL als auch LINQ to Entities, außerhalb von Visual Studio testen.) So warum würde jemand wollen Entity SQL verwenden?

Es gibt eine Reihe von Gründen.

Beginnen wir mit der Sprache, die, der Sie in code. LINQ ist in c# und Visual Basic. Es ist eine Power-Pack für f#, die LINQ bereitstellt. Wenn Sie in andere Code.NET-Sprache können Sie LINQ nicht verwenden. Aber Sie können dennoch verwenden Entity SQL Abfragen zum Ausdruck bringen. Ich habe auch Entity SQL nützlich gefunden für die Erstellung von komplexen Textsuche in Anwendungen. LINQ ist kombinationsfähige, aber an einem bestimmten Punkt wird es nur einfacher, einfach eine Zeichenfolge zu erstellen.

Sie können auch Abfragen auf einer niedrigeren Ebene in der EF Verbindungen und Befehle zusammen mit einem Entity SQL-Ausdruck ausführen. Dieser Pfad gibt Streamingdaten und eignet sich hervorragend für Berichterstattung oder Daten bewegen.

Abfrage, Codegenerierung und Kontextoptionen

Während ich empfehlen die Verwendung von LINQ to Entities als Ihre Standard-Abfrage-Strategie, haben Sie gesehen, Gründe warum Sie Entity SQL in Rand Fällen nutzen möchten. Dies ist, was ich tun und was ich Kunden empfehlen, und ich freue mich immer nach einer Entschuldigung, meine selten verwendete Entity SQL-Koteletts ausüben. Die Dokumentation auf MSDN ist ziemlich gründlichen für das Lernen, wie Sie Entity SQL-Ausdrücke zu erstellen. Aber anders als das einige alte Blog-posts from the EF-Team und ein Kapitel in meinem Buch "Programming Entity Framework" O' (Reilly Media, 2010), ich nicht viele Ressourcen zum Erlernen der Syntax bewusst bin.

Im Bereich der Codegenerierung ist mit EntityObjects eine feine Strategie Wenn Sie einfache Anwendungen schreiben und Dinge nur arbeiten möchten. Jedoch wenn Sie Anwendungen Architektur sind, wo Sie Dauerhaftigkeit bekannt Klassen haben möchten, verwenden Sie Komponententests und folgen Sie dem Pfad der Trennung von Bereichen, die ist genau das, was für die EF POCO-Unterstützung erstellt wurde. Sogar dann haben Sie einige Flexibilität im Umgang mit reinen Objekte, die ein wenig Extraaufmerksamkeit beim codieren oder Nutzung von der Proxy-Generierung, bei dem das EF-Do seine Arbeit mit wenig Interferenzen erfordern.

Die EF-4.1 wird die Code-Generation, die Wahl zwischen ObjectContext oder DbContext Ihre POCO Klassen zu verwalten, ist eine weitere Option hinzugefügt. Viele Entwickler werden in die DbContext springt, weil es ein einfacher API ist, mit zu arbeiten. Benötigen Sie eine feiner abgestufte Ebene der Kontrolle über die Interaktion mit ändern-Protokollierung, oder lieber nutzen Sie vorhandenen Code oder Wissen der ObjectContext, Sie können weiterhin den ObjectContext als Basis für Ihre Kontext verwenden.

Julie Lerman ist ein Microsoft MVP.NET Mentor und Berater lebt in den Hügeln von Vermont. Finden Sie ihre Präsentation auf Data Access und anderen Microsoft.NET-Themen auf Benutzergruppen und Konferenzen auf der ganzen Welt. Sie Blogs auf thedatafarm.com/blog und ist der Autor von der hoch gelobten Buch "Programming Entity Framework" (O' Reilly Media, 2010). Folgen Sie ihr auf Twitter bei twitter.com/julielerman.

Dank der folgenden technischen Experten für die Überprüfung dieses Artikels: Tim Laverty