In spätestens 2,5 Wochen wird das .NET Framework 3.5 released, und damit geht auch LINQ in die finale Version. Was ich mich gerade frage:

Wozu braucht man das überhaupt? Wo seht ihr Einsatzgebiete?

Hintergrund: ich arbeite seit einiger Zeit strikt mit eigenen Geschäftsobjekten und eigenen Datenzugriffsklassen, in denen ich das O/R-Mapping mache bzw. den Datenzugriff kapsele. In der Anwendung selbst arbeite ich also immer mit streng typisierten Objekten, mit SQL komme ich nur innerhalb der Datenbank in Stored Procedures in Berührung, Daten befülle ich via DataReader in meine Objekte. Ich wüsste nicht, welchen Vorteil mir an dieser Stelle die Verwendung von LINQ bringen sollte. Und ich wüsste ehrlich gesagt auch nicht, an welcher Stelle man sonst, außer bei Dummies, Datenzugriffscode benötigt.

Kommentare

#1 Jürgen Gutsch schrieb am Dienstag, 13. November 2007 08:39:00:
Moin Thomas,

LINQ macht genau das was du "seit einiger Zeit strikt" machst. LINK to SQL ist ein O/R Mapper, der dir deine Datenbank mit "streng typisierten Objekten" abbildet. Mit SQL brauchst du nicht in Berührung zu kommen, außer beim Erstellen von Stored Procedures. Der Datenzugriffscode? Den bekommt man nicht mit, der ist unwichtig, wenn das Mapping steht. (Übrigens kann das Mapping in zwei Minuten stehen, wenn man eine fertige Datenbank hat.) Und den Datareader? Kann man mit guten Gewissen in seinem Namespace verstauben lassen; wird mit LINQ nicht mehr direkt benötigt.

Aber da du das alles schon selber hast, brauchst du es ja nicht. Wozu auch? ;-)


Gruß Jürgen
PS: Sorry, aber das musste jetzt sein ;-)
#2 Thomas schrieb am Dienstag, 13. November 2007 10:46:00:
Kein Problem ... ein wirkliches KO-Argument konntest du ja auch nicht liefern :-).

Letztendlich könnte ich damit in den Data-Access-Klassen auf das letzte Bisschen nicht typisierten Code (DataReader) verzichten, erzeuge aber damit letztlich wieder (unnötigen) Overhead, wie jetzt z.B. schon beim Generieren von Typed DataSets.
#3 Jürgen Gutsch schrieb am Dienstag, 13. November 2007 11:09:00:
genau, wobei du mit LINQ sogar auf die Typed DataSets verzichten köntest, da LINQ eh alles streng typisiert in entsprechenden Listen zurückgibt. Alles nochmal in Typed DataSets abzubilden wäre IMHO doppelt gemoppelt...
Hast du die Artikel vin Scott Guthrie zu dem Thema gelesen? Wahrscheinlich schon...
(http://weblogs.asp.net/scottgu/archive/tags/LINQ/)
#4 Thomas schrieb am Dienstag, 13. November 2007 11:28:00:
Jepp. Das Typed DataSet war jetzt eigentlich nur ein Beispiel aus der "Jetztzeit" für unnötigen Overhead. Der mag mit LINQ geringer ausfallen, aber im Hintergrund muss das O/R-Mapping ja gemacht werden - ich hab's mir noch nicht angeschaut, aber ich würde vermuten, dass da an letzter Stelle auch wieder ein DataReader stehen wird.

Von daher sehe ich in dem konkreten Fall keinen Bedarf, mal abgesehen von einem Dummy, den man schnell zusammenzimmern muss, wo das ne große Hilfe sein kann.

Eigentlich verführt es sogar, wieder Business Logic mit Datenzugriff zu vermischen, am besten noch im CodeBehind/CodeBeside wieder alles zu machen ...
#5 Alex schrieb am Dienstag, 13. November 2007 12:11:00:
In der Tat ist die Versuchung groß, wieder alles zu mischen, da ja jetzt alles nach Business-Objekten aussieht. Aber wenn man es weiß, ist es ja kein Problem, es sauber zu lösen ;-)
Probiers einfach mal aus - ich war auch erst skeptisch aber es ist wirklich angenehmer. Vor allem LINQ to XML gefällt mir gut.
#6 Jürgen Gutsch schrieb am Dienstag, 13. November 2007 12:17:00:
Dito. Da kann ich Alex nur zustimmen :-)
#7 Thomas schrieb am Dienstag, 13. November 2007 13:38:00:
Tut mir wirklich leid, ich sehe da im oben beschrieben Fall einfach keinerlei Vorteile, siehe Anmerkungen zum Overhead ...
#8 Alex schrieb am Dienstag, 13. November 2007 13:59:00:
Es zwingt Dich ja niemand...
#9 Thomas schrieb am Dienstag, 13. November 2007 14:25:00:
Natürlich nicht :) Ich wäre nur gerne überzeugt worden ... deswegen ja auch der provokative Titel. Aber gut, dann machen wir da einfach einen Haken dahinter und vergessen es. Wie man liest steht das nächste Datenzugriffs-Konzept, was LINQ letztlich wieder über den Haufen wirft, ja sowieso schon an.
#10 Thomas Höhler schrieb am Dienstag, 13. November 2007 15:50:00:
In der letzten Ausgabe des dotnetmagazin ist das Thema LINQ mit LING to SQL und LINQ to DataSet ganz gut beschrieben. Nach meinem Verständnis stellt es eine gute Alternative zu den nicht immer guten und nicht immer intuitiven O/R-Mappern dar. Werde ich mir zumindestens mal genauer Ansehen.

Dein Kommentar