Laden...

Linq2MySQL - Was haltet ihr davon?

Erstellt von EgoFelix vor 15 Jahren Letzter Beitrag vor 15 Jahren 4.426 Views
E
EgoFelix Themenstarter:in
38 Beiträge seit 2009
vor 15 Jahren
Linq2MySQL - Was haltet ihr davon?

verwendetes Datenbanksystem: mysql / mssql

Da ich das DBML Schema des linq2sql sehr gut fand, und mir bereits ein Datenbankmodul zum Erstellen der Datenbank eingeladen via Modulen (Jedes Modul hat seine eigene Datenbank und kann diese an das DB-Objekt übergeben), wollte ich dies natürlich weiter benutzen. Folgendes kam dabei heraus und ich wollte mal fragen was Ihr davon haltet. Das Beispielprojekt legt euch eine Einstellungsdatei an. Diese findet Ihr unter: Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData) + "\fwsoftware_settings.xml".

So nun zum Linq2MySQL.
Ich habe ein Beispielprojekt angehängt, in dem alles drin ist. Dort funktioniert der Zugriff auf MySQL genauso wie auf MsSQL. Alles was Ihr benötigt ist der MySQL-Net Connector. Die Tabellen müsst ihr eben per Hand erstellen, ich habe ein Skript in das Archiv gepackt, welches dies für euch tut.

Der Vorteil dieser Methode ist für mich, dass ich mit meinem Datenbank-Objekt (nicht in der Demo enthalten, daher das Skript zum Erstellen) eben alles sofort erstellen kann, auch Modulübergreifend (Ich verwende das Datenbank-Object in allen Modulen), und somit sehr effektiv arbeiten kann.

Gibt es bessere Lösungsansätze?

Mit freundlichen Grüßen
Felix

Mit freundlichen Grüßen
Felix

3.430 Beiträge seit 2007
vor 15 Jahren

Hallo EgoFelix,

also das Thema LinqToSql wurde hier schon sehr heftig diskutiert.
Linq2SQL auf dem Abstellgleis

Viele (so auch ich) sind der Meinung dass Linq nur so nebenbei zu ADO.NET entwickelt wurde und dass es eigentlich nur gemacht wurde um jeden zu zeigen was mit LINQ möglich ist.
Aber es gibt ein paar Dinge die an LINQ störend sind, deshalb ist es wahrscheinlich besser wenn du dich in ADO.NET einarbeitest, denn das ist um einiges mächtiger.
Wenn du willst kannst du ja dann LINQ nehmen um mit den DataSets zu hantieren 😃

Ich selbst habe in einem Projekt auch schon Linq verwendet. Das funktioniert für etwas Einfaches auch sehr gut, aber wenn man etwas komplexes aufbauen will, so kommt man doch relativ schnell an die Grenzen von LINQ.

Gruss
Michael

E
EgoFelix Themenstarter:in
38 Beiträge seit 2009
vor 15 Jahren

Ich selbst habe in einem Projekt auch schon Linq verwendet. Das funktioniert für etwas Einfaches auch sehr gut, aber wenn man etwas komplexes aufbauen will, so kommt man doch relativ schnell an die Grenzen von LINQ.

Hast du dafür mal ein Beispiel? Ich wüsste so aus dem Stehgreif nichts...

Mit freundlichen Grüßen
Felix

3.430 Beiträge seit 2007
vor 15 Jahren

Hallo,

Hast du dafür mal ein Beispiel? Ich wüsste so aus dem Stehgreif nichts...

Ja da gibt es schon einiges.
Wenn du hier im Forum nach Linq2SQL oder LinqToSql suchst, dann siehst du ein paar Probleme die oft auch ungelöst blieben.

Weitere Nachteile findest du in dem von mir geposteten Thread.

Also besser ist meiner Meinung (und ich bin da nicht der Einzigste) ADO.Net oder einen anderen OR-Mapper zu verwenden.

Gruss
Michael

365 Beiträge seit 2007
vor 15 Jahren

Hallo EgoFelix,

Ich kann mich michlG's Meinung nur anschliessen.
Für kleine Abfragen um mal schnell was zusammenzubasteln mit 1 - 2 Tabellen
ist LINQ super ...... Echt ne feine Sache ......

Bei größeren Projekten verlierst du schnell den Überblick und dein Code bläht
sich ungemein auf.
Wenn dann setzte direkt auf das Entity Framework, denn LINQ wird nicht mehr weiterentwickelt.
Unser Redmonder Verein hat 2 Abteilungen mit quasi derselben Aufgabe beauftragt,
so wie Ich es verstanden habe einen OR - Mapper zu entwickeln ....
2 verschiedene Produkte des gleichen Themas kann sich kaum eine bis keine Firma leisten.
Das verunsichert die Kunden und Entwickler ....

Wenn du der Meinung bist, das ist die Technologie die du benutzen willst mach es,
aber benutze das Entity Framework.
Würde dir aber auch empfehlen ADO.Net zu benutzen.

Hallo michlG:

Also besser ist meiner Meinung (und ich bin da nicht der Einzigste) ADO.Net oder einen anderen OR-Mapper zu verwenden.

ADO.Net ist ein OR-Mapper 🤔
Muh ... Vielleicht eine Definitionssache .... hehe ....

[Meine Meinung]
Ich kann damit nichts anfangen weil Ich nicht die totale Kontrolle darüber habe was passiert.
Im Hintergrund werden etliche Klassen angelegt.
Logisch ist es schön LINQ zu benutzen und weniger lernen zu müssen ....
Verhält sich genauso mit dem Designer, habe Ihn schon in der Ausbildung
gemeidet. Konnte kaum einer meine Mitschüler verstehen .... hrhrhr ....
Aber hey, Ich kann nur sagen Ich denke zu wissen was im Hintergrund läuft....
Es geht beim proggen doch meistens nur um Datenhaltung/änderung/speicherung,
auch wenn du Logik zur Handhabung der Daten entwickelst.
Vielleicht sehe Ich das falsch, aber es hat mir nicht geschadet.
[/Meine Meinung]

Greetz da kubi.

3.430 Beiträge seit 2007
vor 15 Jahren

Hallo Kubi,

ADO.Net ist ein OR-Mapper
Muh ... Vielleicht eine Definitionssache .... hehe ....

Ja dieser Satz ist ein bisschen verunglückt 😃
Das "anderen" hätte da eigentlich nicht hingehört.

Gruss
Michael

365 Beiträge seit 2007
vor 15 Jahren

hehehe ....
Dachte schon, soll Ich es posten oder verkneif Ich mir die Frage. 😉
Ich hab schon verstanden was du sagen wolltest ....

5.941 Beiträge seit 2005
vor 15 Jahren

Hallo zusammen

Ich selbst habe in einem Projekt auch schon Linq verwendet. Das funktioniert für etwas Einfaches auch sehr gut, aber wenn man etwas komplexes aufbauen will, so kommt man doch relativ schnell an die Grenzen von LINQ.

Beispiel bitte 😃
In deinem geposteten Link finde ich nichts.
Redest du jetzt von LinqToSql oder von LINQ selber?

Wenn du der Meinung bist, das ist die Technologie die du benutzen willst mach es,
aber benutze das Entity Framework.
Würde dir aber auch empfehlen ADO.Net zu benutzen.

LinqToSql ist ein OR / Mapper für den SqlServer, das Entity Framework ein OR / Mapper für verschiedene Datenbanken, also dass was ein OR / Mapper schlussendlich auch ausmacht.
Diese direkt zu vergleichen halte ich nicht für sinnvoll.

Ich würde nicht mehr ADO.NET benutzen, sondern einen OR / Mapper.
Vorteile davon finden sich bspw. im verlinkten Thread weiter oben.
Wieso empfiehlst du ADO.NET?

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

X
1.177 Beiträge seit 2006
vor 15 Jahren

huhu,

also ADO ist eigentlich schon etwas älter - war mal als Ersatz für ODBC gedacht hats aber nie geschafft. Zu .net hat man dann um diese Technik zu retten ADO.net gemacht - dies war aber wiederum wohl eher als "übergangslösung" gedacht bzw. etwas Stiefmütterlich behandelt.

Was mir in dieser Diskussion eigentlich fehlt ist der Hinweis, dass man doch ohne Probleme verschiedene Techniken mischen kann. Z.B. LINQ mit Entity Framework zum anzeigen für Listen, native Treiber für spezielle Operationen (z.B. einen count() absetzen oder komplexere Selects mit geringen Ergebniszahlen)

Das ganze verpackt ihr dann ja eh in einen Layer.

😃

Xynratron

Herr, schmeiss Hirn vom Himmel - Autsch!

Die Erfahrung zeigt immer wieder, dass viele Probleme sich in Luft auslösen, wenn man sich den nötigen Abstand bzw. Schlaf gönnt.

365 Beiträge seit 2007
vor 15 Jahren

Hallo Peter Bucher,

Hallo zusammen

Ich würde nicht mehr ADO.NET benutzen, sondern einen OR / Mapper.
Vorteile davon finden sich bspw. im verlinkten Thread weiter oben.
Wieso empfiehlst du ADO.NET?

Gruss Peter

Du kennst dich auch mit Relationale Datenbanken aus und hast einen Wissensstand erreicht.

Ich würde ADO.Net empfehlen da es eine Technologie ist die schon ausgereift ist.
Diskussionwürdig 🤔

Du arbeitets dort mit einem 1 zu 1 Abbild deiner Datenbank im Speicher,
lernst also auch mit DB's und Ihren Eigenheiten umzugehen.
OK LINQ ist auch ein 1 zu 1 Abbild, jedoch mit einer anderen herangehensweise.
Mit ADO.Net musst du deine Objekte selbst anlegen, spricht zuerst zwar nicht
für diese Technologie, aber im Endeffekt lernst du dabei Objektorientierte Programmierung.

  • Durch das anlegen eigener Tabellen, PrimaryKeys, Columns, Constraints etc.
    lernst du den Umgang mit Relationale Datenbanken. Meine im Code nicht im Designer.

  • In unserer IT - Landschaft werden wohl wesentlich mehr Programme und
    Firmen die ADO.Net nutzen vorzufinden sein. Das wird sich in Zukunft vielleicht ändern.
    Spreche von den durchschnittlichen Firmen und nicht von Firmen mit Cracks und großen Budgets für Top Entwickler.

  • LINQ lädt im Hintergrund deine Tabellen, du bekommst nicht den Hauch
    einer Ahnung in welcher Reihenfolge und warum.
    Exceptions wirst du dabei auch nicht bekommen, die Ich zu Beginn mit ADO.Net hatte.
    Dadurch habe Ich viel gelernt, vielleicht bin Ich deswegen so ein Verfechter von ADO.Net 👅

Okay, sobald du diese Sachen verinnerlicht hast, spricht nichts dagegen
wie Xynratron erwähnt hat diese Technologien zu mischen.
LINQ und Entity Framework sind ja nichts schlechtes oder böses.
Das wollte Ich nicht damit zum Ausdruck bringen.
Sie vereinfachen den Zugriff, aber hier liegt auch der Hund begraben.
Du bekommst Entwickler, die keinen Plan davon haben was im Hintergrund passiert.

Greetz da kubi.

5.941 Beiträge seit 2005
vor 15 Jahren

Hallo kubi

Ich kann gut lesen, du brauchst meinen Namen nicht fett zu schreiben 😉

Du solltest natürlich schreiben, was du für Motive zu deiner Empfehlung hast.
Ich sehe natürlich ein, was du da schreibst und ich halte sehr viel davon etwas allgemeineres zu benutzen, um daraus zu lernen.

Ich habe eine Empfehlung allerdings so verstanden, was produktiv genutzt werden sollte.
Und heute macht niemand mehr eine neue Anwendung ohne einen OR / Mapper bzw. eine eigene Implementierung - also ohne auf Objekte zu mappen, ausser es sind ganz spezielle Anforderungen, die es nicht ermöglichen.

Das Entity Framework nutzt in der obersten Schicht sowieso LINQ, also sind diese Technologien out-of-the-box schon zusammen, man muss da nichts manuell mischen 😃

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

365 Beiträge seit 2007
vor 15 Jahren

Hallo Peter Bucher,

okay dann schreib Ich ihn nicht mehr FETT 😁

Gebe dir im Grunde Recht für immer wiederkehrende Aufgaben einen OR/Mapper zu benutzen,
anstatt jedesmal die Klassen von Hand zu schreiben. Ist halt produktiver.
Jedoch sehe Ich Geschwindigkeit nicht immer als höchste Anforderung.
Ist bei jedem unterschiedlich und das ist auch gut so,das belebt die IT - Landschaft. 😉

Greetz da kubi.

3.003 Beiträge seit 2006
vor 15 Jahren

Ich arbeite seit knapp 3 Wochen an einem Projekt, das eine Schnittstelle zwischen einem Programm, das auf dem SqlServer arbeitet, und einem, das auf MySql arbeitet, realisieren soll. Die Tabellen sind strukturell und inhaltlich nicht gleich.

Schlussendlich also Daten (bidirektional) lesen, umformen, schreiben. Nach ersten Versuchen mit ADO.NET bin ich zurück zum Entity Framework, als ich endlich einen EF-Provider für MySql gefunden hab. Was soll ich sagen - einfach nur geniale Sache. Würde ich jederzeit empfehlen, was ich hiermit tue 😉.

Einen kleinen Haken hat die Sache (noch). Während IBM (Db2, Informix), NpgSql (PostgreSQL), Phoenix (SQLite) und Firebird als Hersteller von den entsprechenden DBMS schon seit Monaten Provider fürs Entity Framework anbieten, lässt Sun genau EINEN Entwickler (Reggie Burnett, wem das was sagt) dran arbeiten, und legt dem auch noch jede Menge Steine in den Weg - bis zum heutigen Tag gibt es keinen "offiziellen" ADO.NET-Provider mit EF-Support für MySql (Connector/.NET 6.0 wäre das dann). Man ist also auf den exzellenten, aber nicht kostenfreien Provider von DevArt angewiesen. Gibt eine 30-Tage-Testversion davon - wer MySql und Entity Framework mal in Aktion sehen möchte, dem sei das wärmstens empfohlen.

So, wie ich das sehe, sieht es so aus:

  • schnell mal Daten aus einer DB holen: ADO.NET
  • kleinere, private Programme oder kleine Helper in mittelständischen Umgebungen: LinqTo(My)Sql (und nein, es ist NICHT tot 👅 )
  • komplexe Programme in sich verändernden Umgebungen: Entity Framework

Da EF in der Anwendung (nicht im Entwurf) LinqTo(My)Sql oberflächlich ähnelt, würde ich zum Üben und Lernen zu EF raten.

Gruß,

LaTino
EDIT: typo

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

1.433 Beiträge seit 2006
vor 15 Jahren

Das Entity Framework nutzt in der obersten Schicht sowieso LINQ, also sind diese Technologien out-of-the-box schon zusammen, man muss da nichts manuell mischen 😃

Stimmt.

Aber irgendwie war ja der ThreadTitel nicht LinqToSQL sondern LinqToMySQL und es entfacht sich hier ein Diskussion über die vorhandenen O /R Mapper.

@Threadersteller
Wenn Du einen O /R Mapper einsetzen willst, dann kannst Du dies entweder mit
NHibernate oder Entity Framework.

Erstgenanntes ist schon länger verfügbar und ich denke ein wenig erprobter (ich selber nutze privat auch EF). Hier in der Firma verwenden wir NHibernate und für die Zusammenstellung der Ergebnisse LINQ, aber num GUI, damit die Daten so formatiert daher kommen wie sie sollten.

(Anzahl Geräte, aber nur die Bezeichnung einmal anzeigen und die Anzahl als Summe ausgeben).

Falls mal eine Weblösung mit NHibernate entstehen sollte, dann ist dieser Link noch recht lesenswert.

Grüsse
Daniel
Space Profile
Wer nicht fragt, der nicht gewinnt

365 Beiträge seit 2007
vor 15 Jahren

Da EF in der Anwendung (nicht im Entwurf) LinqTo(My)Sql oberflächlich ähnelt, würde ich zum Üben und Lernen zu EF raten.

Kann Ich unterstreichen ....

Das Entity Framework nutzt in der obersten Schicht sowieso LINQ, also sind diese Technologien out-of-the-box schon zusammen, man muss da nichts manuell mischen 🙂

Unterstreicht das nochmal ⚠

Aber irgendwie war ja der ThreadTitel nicht LinqToSQL sondern LinqToMySQL und es entfacht sich hier ein Diskussion über die vorhandenen O /R Mapper.

Deswegen klink Ich mich jetzt aus 😁

Greetz da kubi.

3.430 Beiträge seit 2007
vor 15 Jahren

Hallo Peter,

Beispiel bitte 🙂
In deinem geposteten Link finde ich nichts.
Redest du jetzt von LinqToSql oder von LINQ selber?

Ich habe mich gestern in meinen Beitrag leider mehrmals schlecht ausgedrückt.
Ich habe natürlich gemeint dass man mit LINQTOSQL relativ schnell mal an seine Grenzen stosst. Und genau das ist bei Linq nicht der Fall. 🙂

Wieso empfiehlst du ADO.NET?

Da ich momentan Student bin und erst relativ kleinere Datenbank-Projekte gemacht habe hat mir ADO.NET auch immer ohne Probleme funktioniert.
Ein OR-Mapper ist sicherlich auch nicht schlecht, aber das braucht halt doch mehr Einarbeitungszeit als mit ADO.NET schnell etwas zusammenzubauen.

Wobei man bei einem großen Projekt wahrscheinlich besser unterwegs wäre als mit ADO.NET 🙂
Da gibt es aber auch einige Forumsmitglieder die auf ADO.NET schwören und nie im Leben einen OR-Mapper verwenden würden. Ich will da aber keine Namen nennen 😉

Also da gibt es verschiedene Meinugen was besser ist und ich habe mich persönlich noch nicht wirklich festgelegt, da mir noch die Erfahrung fehlt. X(

Gruss
Michael

Deswegen klink Ich mich jetzt aus

Ich mich auch und entschuldige mich vielmals für das entfachen der O/R Mapper - Diskussion 😉

E
EgoFelix Themenstarter:in
38 Beiträge seit 2009
vor 15 Jahren

Das lässt für mich nur den Schluss übrig, dass es viele Technologien gibt, aber keine wirklich das A&O ist. Mal ist dies, mal ist das besser. Schade eigentlich. Da werd ich mir doch mal alles anschauen müssen, um zu entscheiden was für mich so am besten einzusetzen ist.

Vielen Dank

Mit freundlichen Grüßen
Felix