Übersicht über LINQ to Entities

Die meisten Geschäftsanwendungen werden derzeit geschrieben, um auf Daten in relationalen Datenbanken zuzugreifen. Daher müssen diese Anwendungen mit den relational abgebildeten Daten interagieren. Das relationale Modell ist für ein effizientes Speichern und Abrufen optimiert, jedoch nicht für das bei objektorientierter Programmierung verwendete konzeptionelle Modellieren. Verschiedene normalisierte Tabellen entsprechen oft einer einzigen Klasse, und Beziehungen zwischen Klassen werden nicht auf dieselbe Weise dargestellt wie Beziehungen zwischen Tabellen. Entwickler von Geschäftsanwendungen müssen oft mit zwei (oder mehr) Programmiersprachen arbeiten: mit einer allgemeinen Programmiersprache für Geschäftslogik und Präsentationsebenen (wie Visual C# oder Visual Basic) sowie einer Abfragesprache für die Interaktion mit der Datenbank (z. B. Transact-SQL). Der Entwickler muss also mehrerer Sprachen mächtig sein, um seine Arbeit effektiv erledigen zu können. Außerdem sind dadurch Sprachkonflikte in der Entwicklungsumgebung vorprogrammiert. So ergibt es sich beispielsweise, dass eine Anwendung, die zur Ausführung einer Abfrage von Daten aus einer Datenbank eine Datenzugriffs-API verwendet, die Abfrage als Zeichenfolgenliteral angibt, indem sie Anführungszeichen verwendet. Diese Abfragezeichenfolge ist jedoch für den Compiler nicht lesbar und wird nicht auf Fehler (Syntaxfehler, tatsächliche Existenz der Spalten oder Zeilen, auf die verwiesen wird, usw.) überprüft. Auch der Typ der Abfrageparameter wird nicht geprüft, und es gibt keine IntelliSense-Unterstützung.

Mithilfe von Entity Framework können Entwickler mit Daten in der Form domänenspezifischer Objekte und Eigenschaften arbeiten, wie z. B. Kunden und Kundenadressen, ohne sich über die zugrunde liegenden Datenbanktabellen und -spalten Gedanken machen zu müssen, in denen diese Daten gespeichert sind. Weitere Informationen finden Sie unter Entity Data Model. Mit LINQ können Entwickler in ihrem Anwendungscode mengenbasierte Abfragen formulieren, ohne dazu auf eine separate Abfragesprache zurückgreifen zu müssen. Über die Object Services-Infrastruktur von Entity Framework stellt ADO.NET eine allgemeine konzeptionelle Sicht von Daten bereit, einschließlich relationaler Daten wie Objekten in der .NET-Umgebung. Dadurch wird die Objektebene zu einem optimalen Ziel für die LINQ-Unterstützung. Mit dieser LINQ-Technologie, LINQ-to-Entities, können Entwickler flexible, stark typisierte Abfragen für Entity Framework-Objektkontext erstellen, indem LINQ-Ausdrücke und die LINQ-Standardabfrageoperatoren direkt von der Entwicklungsumgebung aus verwendet werden. Die Abfragen werden in der Programmiersprache selbst ausgedrückt, und nicht als in den Anwendungscode eingebettete Zeichenfolgenliterale, wie dies bei in Microsoft .NET Framework, Version 2.0 geschriebenen Anwendungen normalerweise der Fall ist. Syntaxfehler sowie Fehler bei Membernamen und Datentypen werden vom Compiler erkannt und zur Kompilierungszeit protokolliert. Dadurch verringert sich das Potenzial für Typenprobleme zwischen Entitätsdatenmodell und der Anwendung.

LINQ-to-Entities-Abfragen verwenden die Object Services-Infrastruktur. Die ObjectContext-Klasse ist die primäre Klasse für die Interaktion mit einem Entitätsdatenmodell als CLR-Objekte. Der Entwickler erstellt über den ObjectContext eine generische ObjectQuery-Instanz. Die generische ObjectQuery-Klasse stellt eine Abfrage dar, die eine Instanz oder eine Auflistung von typisierten Entitäten zurückgibt. Die zurückgegebenen Entitätsobjekte sind aktualisierbar und befinden sich im Objektkontext. Dies gilt auch für Entitätsobjekte, die als Member anonymer Typen zurückgegeben werden.

In diesem Abschnitt

Siehe auch

Weitere Ressourcen

LINQ to Entities