LINQ und ADO.NET
Aktuell müssen viele Entwickler von Geschäftsanwendungen mit zwei (oder mehr) Programmiersprachen arbeiten: mit einer allgemeinen Programmiersprache für die Geschäftslogik- und die Darstellungsschicht (wie Visual C# oder Visual Basic) und 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 z. B., 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 für den Compiler nicht lesbar und wird nicht auf Fehler (Syntaxfehler, tatsächliche Existenz der Spalten oder Zeilen, auf die verwiesen wird, usw.) geprüft. Auch der Typ der Abfrageparameter wird nicht geprüft, und es gibt keine IntelliSense-Unterstützung.
LINQ (Language Integrated Query) ermöglicht es Entwicklern, in ihrem Anwendungscode mengenbasierte Abfragen zu formulieren, ohne eine separate Abfragesprache verwenden zu müssen. Sie können LINQ-Abfragen für die verschiedensten aufzählbaren Datenquellen (also Datenquellen, die die IEnumerable-Schnittstelle implementieren) wie beispielsweise speicherresidente Datenstrukturen, XML-Dokumente, SQL-Datenbanken und DataSet-Objekte schreiben. Auch wenn diese aufzählbaren Datenquellen auf unterschiedliche Art und Weise implementiert sind, weisen sie doch alle dieselben Syntax- und Sprachkonstrukte auf. Da Abfragen direkt in der Programmiersprache formuliert werden können, benötigen Sie keine andere Abfragesprache, mit der Abfragen als Zeichenfolgenliterale eingebettet werden, die vom Compiler weder gelesen noch geprüft werden können. Durch die Integration von Abfragen in die Programmiersprache werden Visual Studio-Programmierer auch in die Lage versetzt, durch Typ- und Syntaxprüfungen zur Kompilierzeit und IntelliSense produktiver zu arbeiten. Mit diesen Funktionen wird der für die Beseitigung von Abfragefehlern erforderliche Aufwand beträchtlich reduziert.
Das Übertragen von Daten aus SQL-Tabellen in Objekte im Arbeitsspeicher ist häufig nervenaufreibend und fehleranfällig. Der LINQ-Anbieter, der von LINQ to DataSet und LINQ to SQL implementiert wird, konvertiert die Quelldaten in IEnumerable-basierte Objektauflistungen. Dem Programmierer werden die Daten stets als IEnumerable-Auflistung angezeigt, gleich ob bei einer Abfrage oder bei einem Update. Für das Schreiben von Abfragen für diese Auflistungen steht uneingeschränkte IntelliSense-Unterstützung zur Verfügung.
Es gibt drei separate ADO.NET-LINQ-Technologien (Language Integrated Query): LINQ to DataSet, LINQ to SQL und LINQ to Entities. LINQ to DataSet ermöglicht genauere, optimierte Abfragen über das DataSet. LINQ to SQL ermöglicht die direkte Abfrage von SQL Server-Datenbankschemas, und mit LINQ to Entities können Sie ein Entity Data Model abfragen.
Das folgende Diagramm ermöglicht eine Einordnung der ADO.NET LINQ-Technologien im Kontext von allgemeinen Programmiersprachen und anderen LINQ-fähigen Datenquellen.
Weitere Informationen zu LINQ finden Sie unter Language-Integrated Query (LINQ).
Die folgenden Abschnitte enthalten weitere Informationen zu LINQ to DataSet, LINQ to SQL und LINQ to Entities.
LINQ to DataSet
Das DataSet ist ein wichtiges und weit verbreitetes Element des nicht verbundenen Programmiermodells, auf dem ADO.NET basiert. Mit LINQ to DataSet können Entwickler umfangreichere Abfragefunktionen in DataSet integrieren, indem Sie denselben Abfrageformulierungsmechanismus verwenden, der auch für viele andere Datenquellen zur Verfügung steht. Weitere Informationen finden Sie unter LINQ to DataSet.
LINQ to SQL
LINQ to SQL ist ein nützliches Tool für Entwickler, die keine Zuordnung zu einem konzeptionellen Modell benötigen. Mit LINQ to SQL können Sie das LINQ-Programmiermodell direkt über das vorhandene Datenbankschema verwenden. LINQ to SQL bietet Entwicklern die Mögichkeit, .NET Framework-Klassen zu generieren, die Daten darstellen. Diese generierten Klassen werden nicht einem Konzeptdatenmodell zugeordnet, sondern die Zuordnung erfolgt direkt zu Datenbanktabellen, Ansichten, gespeicherten Prozeduren und benutzerdefinierten Funktionen.
LINQ to SQL ermöglicht Entwicklern, Code direkt für das Speicherschema zu schreiben und dabei neben anderen Datenquellen (z. B. XML) dasselbe LINQ-Programmiermuster wie bei speicherresidenten Auflistungen und dem DataSet zu verwenden. Weitere Informationen finden Sie unter LINQ to SQL.
LINQ to Entities
Die meisten aktuellen Anwendungen basieren auf relationalen Datenbanken. Daher müssen diese Anwendungen mit den relational abgebildeten Daten interagieren. Datenbankschemas sind nicht immer optimal für das Erstellen von Anwendungen geeignet, und die konzeptionellen Modelle von Anwendungen weichen von den logischen Modellen der Datenbanken ab. Das Entity Data Model ist ein konzeptionelles Datenmodell, das zum Modellieren der Daten einer bestimmten Domäne verwendet werden kann, sodass Anwendungen mit den Daten als Objekte interagieren können. Weitere Informationen finden Sie unter ADO.NET Entity Framework.
Durch das Entity Data Model werden relationale Daten als Objekte in der .NET-Umgebung verfügbar gemacht. Dadurch wird die Objektebene zu einem optimalen Ziel für die LINQ-Unterstützung, die es Entwicklern ermöglicht, Abfragen an die Datenbank in der Sprache der Geschäftlogik zu formulieren. Dies wird auch als LINQ to Entities bezeichnet. Weitere Informationen Sie unter LINQ to Entities.