Wer erinnert sich noch an das Getöse vor dem Launch von .NET 2.0 und Visual Studio 2005 vor ziemlich genau zwei Jahren? Damals konnte man auf jedem Evangelisten-Vortrag hören, wie sehr die neue .NET-Generation die Produktivität steigert und wie viel Code man einspart.
Sicherlich - es war ein gewaltiger Schritt nach vorn. Wer aber das Märchen der 70%-Codeersparnis glauben wollte wurde dann spätestens in der harten Realität des Arbeitsalltags wieder eingeholt - richtige Anwendungen lassen sich nunmal nicht im Designer zusammenklicken, wie es z.B. bei ASP.NET versucht wurde zu verkaufen.
Mit .NET 3.5 hat nun LINQ Einzug gehalten. Eine Technologie, die von vielen, einschließlich mir, zuerst als eine Art typisierten SQL-Ersatz abgetan wurde, und mit der bis heute viele nichts so richtig anfangen können.
Nachdem ich in den letzten Wochen ein wenig getestet und zuletzt auch produktiv damit gearbeitete habe, kann ich nur sagen: Leute, schaut euch das an! Es kann euch wirklich viel, viel Zeit sparen. Und das nicht nur beim Abfragen von Datenbanken, sondern auch (und vor allem) bei XML z.B. - einem der sicherlich unbeliebtesten Formate in Sachen Erstellung, Einlesen und Bearbeitung überhaupt.
Bei LINQ to SQL muss man nicht unbedingt alle Möglichkeiten nutzen, die es dem Anschein nach bietet. Ich bin zum Beispiel ins Grübeln gekommen, ob das bisherige Modell, nachdem ich meine Anwendungen aufbaue, damit noch Gültigkeit hat. Die Antwort ist: ja - zumindest so lange bis das ADO.NET Entity Framework fertig ist (mehr dazu demnächst). Soll heißen: ich habe schlicht mein eigenes O/R-Mapping via "DataReader to Object", also die Stelle an der ich Daten aus der Datenbank manuell via Stored Procedure abgerufen und dann mit einem DataReader an meine Objekte gebunden habe, durch "LINQ to SQL to my Object" ersetzt.
Alleine die Zeit die ich mir durch den Verzicht auf die Stored Procedure spare ist schon hochgerechnet auf einige Abfragen nennenswert, dazu kommt aber noch ein anderer, eher weicher Faktor: beim Entwickeln bleibe ich vollständig in meiner IDE und meiner Sprache, d.h. ich entwickle in C# und frage auch in C# ab - kann den Debugger nutzen und muss nicht auf SQL wechseln, wo sowohl die Syntax anders ist als auch das Debuggen eher einem Trial&Error-Spiel gleicht.
LINQ to SQL ist damit also nicht des Rätsels endgültige Lösung (die könnte das ADO.NET Entity Framework bringen), sehr wohl aber ein gelungener nächster Schritt bei der effizienten Abfrage von Datenbank-Informationen ohne großen Overhead, wie wir ihn noch beim (Typed) Dataset hatten.
Wie steigt man am besten ein?
Zu guterletzt noch ein paar Ressourcen, die mir wesentlich dabei geholfen haben bzw. immer noch helfen den Einstieg zu finden:
- Scott Guthries Artikel-Serie zu LINQ. Jürgen Gutsch hat die entsprechenden Links zusammengefasst.
- Jeffry Palermos LINQ-to-XML-Beispiel. Anhand eines RSS-Feeds sieht man, wie man kinderleicht XML einlesen, typisieren und ausgeben kann.
- Last but not least noch ein Buch: LINQ - Crashkurs. Macht einen ganz guten und hilfreichen Eindruck und ist sicher nützlich wenn man das eine oder andere mal nachschlagen möchte.
