Linq2SQL auf dem Abstellgleis

Hab heute früh diesen Artikel zugemailt bekommen: (kenn den Absender aber nicht)

http://www.infoq.com/news/2008/11/DLINQ-Future

Siehe dazu auch: Diskussion in MSDN-Forum

Hallo tkrasinger,

Microsoft hat momentan zwei OR-Mapper im aktuellen .NET Framework. Linq2SQL und das ADO.NET Entity Framework. Beide machen im groben genau das Selbe. Dabei ist Linq2SQL allerdings eher die Butter-und-Brot-Version. Linq2SQL kann z.B. keine n:m Verknüpfungen mappen und funktioniert nur mit dem Microsoft SQL Server. Das Entity Framework funktioniert auch mit anderen Datenbanken. Zwar sieht die Unterstützung momentan noch etwas mau aus, aber das Entity Framework ist ja auch brandneu und wurde mit dem Service Pack 1 nachgereicht. Und genau das ist der Punkt. Warum zwei OR-Mapper im Framework? Warum den großen und besseren davon mit einem Service Pack nachreichen?

Ich vermute sie sind nicht rechtzeitig fertig geworden und wollten aber unbedingt eine OR-Mapping-Technologie mit der neuen LINQ-Spracherweiterung im Framework 3.5 ausliefern. Also haben sie ausgeliefert, was schon funktioniert hat. Und das war eben Linq2SQL. Nun ist der "richtige" OR-Mapper fertig und der kleine Linq2SQL wird vermutlich immer mehr an Bedeutung verlieren.
Die Frage ist, ob er überhaupt schon eine nennenswerte Bedeutung erlangt hatte? Um in größeren Projekten eingesetzt zu werden, ist Linq2SQL den meisten noch zu neu. Die enge Bindung an den SQL Server ist für viele eher Abschreckend. Die Unterstützung für verteilte Anwendungen in bei Linq2SQL auch eher ernüchternd. Linq2SQL ist auch nicht einfacher anzuwenden, als das Entity Framework. Wozu also noch Linq2SQL, wenn das Entity Framework das Selbe besser macht?

Ich will nochmal anmerken, dass dies nur meine persönliche Theorie und Meinung ist und nicht mit irgendwelchen öffentlichen Statements des Herstellers begründet ist.

Hi,
ich habe mir gestern einen Vortrag von der BASTA angeguckt und in dem wurde gesagt das Microsoft Linq2SQL nicht mehr weiter entwickeln will. Es wurde dann empfohlen voll und ganz auf das ADO.NET Entity Framework zu setzten.
Ich fands selber auch sehr komisch warum Microsoft überhaupt Linq2SQL rausgebracht hat und dann es nicht weiter entwickelt. Da wusste wahrscheinlich ein Team nicht von dem anderen. Schade aber lässt sich schlecht ändern.

Gruß schabe

Hat irgendwer eine Ahnung wann das nächste SP für VS2008 kommt? Im SP1 ist das EF in meinen Tests komplett durchgefallen, da gingen einfachste Sachen nicht.

In einem PDC-Video hab ich gesehen, dass da einiges neue kommen wird, aber ich find keine Aussagen darüber wann MS ein neues SP zur Verfügung stellt (übrigens find ichs ein Hammer das das SP1 über 800MB hat).

Na ja, LINQ to SQL ist ja nur ein (zweitklassiger) Provider für LINQ, dadurch wird LINQ an sich noch nicht überflüssig.

Wo ist das Problem, heute mit LINQ to SQL anzufangen, und später auf EF umzusteigen? Dank LINQ to Entities sollte der Umstieg nicht soooo schwierig sein ...

Wäre nett, wenn MS endlich mal wüßte, was es will, anstatt Entwickler mit dauernd neuen Technologien zuzumüllen.
Scheint ja nicht der erste O/R-Mapper gewesen zu sein.
http://www.heise.de/ix/LINQ-to-SQL-versus-ADO-NET-Entity-Framework--/blog/artikel/115087

Das war doch von Anfang an klar, dass das ADO.NET Entity Framework Microsofts ORM Flagschiff werden wird.

LINQ 2 SQL diente doch mehr als Proof of Concept für LINQ, meiner Ansicht nach. Die Stärke von LINQ ist doch gerade, dass man mittels verschiedener (oder auch eigener) Provider so gut wie alles standardisiert abfragen kann.

Mir schwebt z.B. ein LINQ 2 MyWebService vor.

Ich verstehe das gezether auch nicht, zumal der Satz von den meisten falsch
gelesen wird, also das gleiche Problem wie hier mit Pisa.

We’re making significant investments in the Entity Framework such that as of .NET 4.0 the Entity Framework will be our recommended data access solution for LINQ to relational scenarios. We are listening to customers regarding LINQ to SQL and will continue to evolve the product based on feedback we receive from the community as well.

Was steht denn hier?

Das MS alle Kraft in EF steckt, aber basierend auf dem Feedback der Comunity
an LinQ2Sql weiter entwickeln wird.

Hallo FZelle,

wirkliches Verstehen kann über das Verstehen der Sachaussage hinausgehen. Zu Zeiten des Niedergangs von OS/2 war die Sachaussage von IBM auch immer "OS/2 wird weiterhin voll unterstützt". Aber jeder wusste, das heißt: "Sehen Sie sich möglichst schnell nach was anderem um".

Ich kenne aber die ganze Thematik um LINQ2SQL nicht gut genug, um zu sagen, ob "wir entwickeln LINQ basierend auf dem Feedback der Community weiter" soviel heißt wie: "Lassen Sie die Finger von LINQ2SQL" oder nicht.

herbivore

Ist sicherlich richtig, aber den ( gesprochenen ) Ausführungen einiger MS
Mitarbeiter nach kommt es auf den aufschrei der Comunity an.

Ist es den meisten egal, lassen sie Linq2Sql einschlafen, ist es ein Mandatory
für viele, geht es weiter.

Ich kann nur dieses Ständige MS Basching nicht mehr ab.

Losgetreten wurde die ganze Diskusion übrigens von jemandem, dessen
Projekt derzeit deshalb mit am meisten von diesem Basching profitiert.

Hallo FZelle,

Ist es den meisten egal, lassen sie Linq2Sql einschlafen, ist es ein Mandatory für viele, geht es weiter.

das spricht doch dann aber doch dafür, dass es einschlafen wird. Denn so alt ist ja LINQ2SQL nicht, als das es für viele schon "mandatory" sein könnte.

herbivore

Doch, ich kenne einige Projekte, die das sehr schnell eingesetzt haben.

Viele Freelancer in den USA haben das gleich eingesetzt, da sie sich nicht getraut
haben einen der schon vorhandenen ORMapper einzusetzen, und gegenüber
DataSets sehr viel Produktiver sind.

Der Aufschrei dort ist schon hörbar.

Aber egal was passiert, L2S wird nicht aus dem FW verschwinden, also werden
alle, die eben nur mit SqlServer und Access arbeiten weiterhin damit arbeiten
können.

Diejenigen, die mehr brauchten sind jetzt schon meist bei NHibernate gelandet,
da wird MS es schwer haben.

haben einen der schon vorhandenen ORMapper einzusetzen, und gegenüber
DataSets sehr viel Produktiver sind.

Wie wurde diese Produktivität denn gemessen und verglichen? Klingt nach Behauptung.
Obwohl fast immer über DataSets gescholten wird, halten sie sich seit dem .NET Framework 1.0 hartnäckig und haben sogar im 3.5er Framework und in Visual Studio 2008 modellpflege erhalten. Auch die ADO.NET Synchronisierungsdienste (Offline Fähigkeit out-of-the-box) arbeiten mit DataSets. Das neue Feature in VS 2008, TableAdapter und DataSet-Definition in getrennten Projekten zu halten, macht typisierte DataSets mit ihren Designern besonders für verteilte Anwendungen wieder sehr interessant. Da konnten sie - abgesehen von den früher fest verwursteten TableAdaptern - schon früher punkten, denn DataRows wissen auch nach Serialisierung über Prozess- und Maschinengrenzen hinweg, ob sie Added, Modified, Deleted oder Unchanged sind. Eine Fähigkeit die einfache Objekte einfach nicht haben. Daran kann auch das ausgefeilte Entity Framework nichts ändern. Man hat sich zwar dem Problem angenommen, aber wirklich Spaß macht das Entwickeln von verteilten Anwendungen mit dem Entity Framework deshalb trotzdem nicht. Es ist einiges an zusätzlicher Handarbeit nötig und man kauft sich auch eigentlich unnötige Server-Roundtrips damit sein. Einfach mal einen kleinen WCF-Dienst aufsetzen und CRUD einmal mit Entities und einmal mit DataSets implementieren. Unabhängig davon, wird der Verteilte Ansatz des Entity Frameworks in folgendem Webcast erklärt: LINQ und Konsorten (Teil 8 von 8) - Verteilte Anwendungen mit LINQ to ….
Das Entity Framework ist eine großartige Sache. Ich arbeite selber gerne damit. Es ist aber eben nicht für alle Anwendungsfälle die Erste Wahl.

Auch bei Verwendung von DataSets muss man ja nicht auf LINQ verzichten. Es gibt ja eine LINQ-Implementierung auch für DataSets. DataSets sind im Gegensatz zu Linq2SQL nicht auf dem Abstellgleis. Wer das Beste aus klassischem ADO.NET und LINQ haben will, sollte sich folgenden Artikel ansehen: LINQ to DataSet

Hallo,
das einzigste was mich bei Datasets stört ist die schlechte Typisierung der Felder welche man bei Objekten ja wunderbar hat.

Und das fehlende Intelisense und die teilweise umständlichere Schreibweise :

// Mit DataSet
ds.Tables["Positionen"].Rows[0]["Gesamtpreis"] = (double)ds.Tables["Positionen"].Rows[0]["Menge"] * (double)ds.Tables["Positionen"].Rows[0]["Einzelpreis"]; 
 
// Mit O/R-Mapper
po.Gesamtpreis = po.Menge * po.Einzelpreis;

Grüße Bernd

Hallo zusammen,

Und das fehlende Intelisense und die teilweise umständlichere Schreibweise :

Hm, dem kann ich eigentlich nicht zustimmen. Weil LinqToSql hatte bei mir jedenfalls schon das Intellisense.
Wobei ich euch in den anderen Punkte voll und ganz zustimmen kann.

Für einfache Abfragen ist LinqToSql noch ok, aber wenn man komplizierte Abfragen macht, so stösst man schnell an die Grenzen.

Gruss
Michael

Und das fehlende Intelisense und die teilweise umständlichere Schreibweise :
Hm, dem kann ich eigentlich nicht zustimmen. Weil LinqToSql hatte bei mir jedenfalls schon das Intellisense

ich glaub die fehlende Intellisense hat sich auf die DataSets bezogen ...

Hi,

ich glaub die fehlende Intellisense hat sich auf die DataSets bezogen ...

Stimmt.
Da gibt es das wirklich nicht.
Ich habe nur gedacht, weil der Thread von LinqToSql handelt, dass das auch auf LinqToSql bezogen war.

Gruss
Michael

Und das fehlende Intelisense und die teilweise umständlichere Schreibweise :

// Mit DataSet  
ds.Tables["Positionen"].Rows[0]["Gesamtpreis"] = (double)ds.Tables["Positionen"].Rows[0]["Menge"] * (double)ds.Tables["Positionen"].Rows[0]["Einzelpreis"];   
   
// Mit O/R-Mapper  
po.Gesamtpreis = po.Menge * po.Einzelpreis;  

Grüße Bernd

Wenn du mit typisierten DataSets arbeitest entfällt aber der cast. So schlimm find ich das jetzt auch nicht, ehrlich gesagt. Und der Vorredner meinte noch, die Typisierung sei schlecht? Dies kann ich nicht nachvollziehen, zumindest für typisierte DataSets.

Ausserdem: Das, was du da machst, sollte eigentlich über eine Expression Column abgefackelt werden.

Jetzt fangt mal nicht an über ADO.NET zu lästern 😁

Hallo Leute !

Ja, die fehlende Intelisense bezog sich auf (untypisierte) Datasets.

Typisierte Datasets hatte im im VS 2003 oder VS 2005 mal getestet, aber gleich wieder verworfen : 11.000 Zeilen Code pro Tabelle, bei 90 Tabellen !
Damals sehr unflexibel bei Strukturänderungen in der Datenbank.

Mein O/R-Mapper erzeugt pro Tabelle ca. 1000 Zeilen.

Da meine Datenbank-Methoden den Datenbankaufbau nicht kennen nützen mir typisierte DS eh nichts.

Grüße Bernd

@Rainbird:
Die Diskusion hatten wir schon mal.
Nicht jeder braucht nen AppServer, und viele die mit SmartClient Lösungen arbeiten
haben sich lange Zeit nicht getraut ORMapper einzusetzen.
Durch Linq2Sql, das ja im Prinzip schon seit 2 1/2 Jahren verfügbar ist, haben sich
viele ermutigt gefühlt diese dann doch zu benutzen.

NHibernate hat seit dem einen riesigen Zulauf.
Und in diesem Umfeld ist ein echter ORMapper eben deutlich Produktiver als
DataSet's.

Nicht jeder braucht nen AppServer, ...

Natürlich nicht. Das habe ich auch nicht behauptet. ADO.NET ist auch für ganz herkömmliche Client-Server-Anwendungen bestens geeignet. Ich wollte nur erwähnt haben, dass ADO.NET nicht überholt ist, sondern weiterentwickelt wird. Das wird im Rummel um die neuen Technologieen gerne übersehen.

... und viele die mit SmartClient Lösungen arbeiten
haben sich lange Zeit nicht getraut ORMapper einzusetzen.
Durch Linq2Sql, das ja im Prinzip schon seit 2 1/2 Jahren verfügbar ist, haben sich
viele ermutigt gefühlt diese dann doch zu benutzen.
NHibernate hat seit dem einen riesigen Zulauf.
Und in diesem Umfeld ist ein echter ORMapper eben deutlich Produktiver als
DataSet's.

Das ist eine unfundierte Behauptung! Man kann nicht pauschal sagen, das Eine sei produktiver als das Andere. Ich frage nochmal. Wer hat diese Produktivität wie und wann gemessen? In wie fern soll die eine Technologie produktiver sein?
Ich bezweifle dass man das überhaupt aussagekräftig messen kann.

Es sind eher äußere Einflüsse die entscheidenden Faktoren für die Wahl bestimmter Technologieen. Die Geschichte und Ausrichtung des Teams wäre da z.B. ein wictiger Faktor. Welches Know-How ist im Team bereits vorhanden? Wie wurde es in bisherigen Projekten gamacht? Persönliche Vorlieben von Entscheidern, Projektleitern spielen auch eine nicht unerhebliche Rolle. Die wenigsten werden sich die Mühe machen, die verschiedenen Technologieen einem objektiven Produktivitätsvergleich zu unterziehen.

Die Diskusion hatten wir schon mal.

Ich möchte die Diskussion auch nicht wieder aufrollen. Mich stört nur die Pauschalaussage "A ist in Smart Client Anwendungen eben produktiver als B".

Hallo Zusammen,
also ich kann bestätigen, dass Linq2Sql in etwa 2 Jahren nicht mehr unterstützt werden soll. Allerdigns wird das erst gehen, wenn es zu einer v2 des EF gekommen ist. Denn der jetzige Stand des EF reicht nicht aus (Fehlendes LasyLoading, keine Unterstützung für dynamische Datenbanken, etc.) um alle Anforderungen zu erfüllen.

den ( gesprochenen ) Ausführungen einiger MS
Mitarbeiter nach kommt es auf den aufschrei der Comunity an.

Ist es den meisten egal, lassen sie Linq2Sql einschlafen, ist es ein Mandatory
für viele, geht es weiter. na dann sollten wir doch alle aufschreien 😉

Schließlich ist Linq2Sql nicht wirklich schlecht und für relativ einfache Anforderungen absolut ausreichend. Ein Vorteil ist IMO auf alle Fälle die Einfachheit von Linq2SQL.

Na dann halt doch nicht auf das Abstellgleis:
http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx
(Irgendwie hatte ich das ja vermutet. Macht ja auch keinen Sinn. Schließlich ist LINQ to SQL eine schnelle, einfache und gute Methode um auf den SQL Server zuzugreifen.)

Na dann halt doch nicht auf das Abstellgleis:

>
(Irgendwie hatte ich das ja vermutet. Macht ja auch keinen Sinn. Schließlich ist LINQ to SQL eine schnelle, einfache und gute Methode um auf den SQL Server zuzugreifen.)

Also ich sehe nicht, dass sich da irgendwas verändert hätte ... ?? Was willst du uns mit dem Post sagen? Überseh ich irgendwo was?

bitte auch lesen:

We are listening to customers regarding LINQ to SQL and will continue to evolve the product based on feedback we receive from the community as well.

Mir fehlt einfach die Odbc Unterstützung für L2S. Auch Wenn Odbc als veraltet angesehen wird, ist es momentan die einzige Möglichkeit für mich, etwas mit Datenbanken zu machen, da bei uns kein SQL Server o.Ä vorhanden ist.