Die Language-Integrated Query bleibt in aller Munde – auch wenn LINQ-to-SQL schon wieder “auf dem Abstellgleis steht” (iX, Ausgabe 7 Juli 2009, S. 97) und nur noch wenige Neuerungen erhält. Für diejenigen, die auf LINQ-to-SQL gesetzt haben, nicht auf den EntitFramework-Zug springen können oder wollen und Persistence Ignorance kein Thema ist, könnte PLINQO interessant sein. Der Hersteller verspricht: “It's still LINQ to SQL, but better!”. PLINQO basiert auf CodeSmith Templates und bringt Features wie beispielsweise Entity Detach in die LINQ-to-SQL Welt, ermöglicht es u.a. Manager- und QueryExtensionklassen generieren zu lassen und unterstützt Many-to-Many Relationen. In den NightlyBuilds wurde diese Woche die Unterstützung für einen Caching-Mechanismus implementiert.
Für mich als Plain old CLR Objects (POCO) liebender LINQ-to-* Neuling sind wahrscheinlich Seiten wie 101 LINQ Samples oder diese MSDN Seite ein guter Einstieg, selbst wenn man mit dem spezifischen LINQ-to-SQL nicht in Berührung kommt.
Interessant finde ich in diesem Zusammenhang auch das, was Daniel Simmons (Dev Manager Entity Framework) über Persistence Ignorance (PI) zu sagen hat. Dass man PI seit der Visual Studio 2010 .Net 4.0 Beta 1 auch mit dem EntityFramework hinbekommen kann und schließlich DDD, POCOs und das EntityFramework unter einen Hut bekommen kann, wenn man dieses denn will.
3 Kommentare:
1. linq ist nicht nur das Entity-Framework und LinqToSql sonder eine allgemeine Abfragesprache von .NET 3.5 und höher.
2. Nur weil es keine neuen Features gibt, heißt es noch lange nicht, dass es nicht einsetzbar ist. Die Einfachkeit von LinqToSQL und Geschwindigkeit beim Lesen ist sehr gut. Beim Entity Framework ist es umgekehrt ... langsames lesen schnelles schreiben.
Aber im Web benötige ich eben mehr lesen als schreiben.
3. LinqToSql ist ein guter Start in Linq der noch relativ einfach fällt.
4. Man sollte froh sein, das MS LinqToSQL und Entity-Framework entwickelt und in VStudio integiert. Beide Frameworks sind mehr als gut und wofür man da wieder auf Dritrtanbieter zurückgreifen soll, erschließt sich mir nicht.
Hi Chris,
dein Kommentar liest sich ja geradezu so, als hätt' dich jemand persönlich angegriffen ;-)
Nun, ich habe meinen Beitrag nochmal quer gelesen und muss feststellen, dass du mit deinen vier Punkte womöglich gar nicht Bezug zu meinem Artikel nehmen wolltest, denn ich habe 1. nicht bestritten, dass LINQ eine allgemeine Abfragesprache ist (im Gegenteil: die verlinkten 101 Beispiele machen deutlich, dass Linq-to-SQL nur eine Anwendung der LanguageIntergratedQuery ist), 2. habe ich nicht behauptet, dass es nicht einsetzbar, langsam oder schnell sei, 3. habe ich auch nicht angezweifelt und bei 4. hole ich gerne aus:
Ermöglicht es mir ein Persistenzframework beispielsweise nicht Caching zu verwenden, ein Drittanbieterwerkzeug erlaubt mir es jedoch einen solchen Cachingmechnismus generieren zu können, kann man ggf. über die Unzulänglichkeiten des Frameworks hinwegsehen, wenn man eben zu diesem Drittanbieterwerkzeug greift.
Ein anderes Beispiel aus dem PLINQO-Blog (http://snurl.com/lbk5a)
"In LINQ to SQL every query is a trip to the database. It doesn't matter if you have five queries in succession that require no logic in between, you must still make each and every query separately." Wenn mir ein Tool nun etwas (eine Extensionsmethod beispielsweise) generieren kann, die es mir ermöglichen, in einer Transaktion mehrere Queries durchzuführen, rechtfertigt das doch den Einsatz eines solchen Tools, oder? Sicher, man kann sich einen solchen Mechanismus selber schreiben - generieren ist doch aber weitaus praktischer, oder bin ich da zu bequem?
Zwar etwas älterer Post, aber immer noch interessant.
Mit POCO Grüssen,
Thomas Sczyrba
Kommentar veröffentlichen