Laden...

O/R-Mapper vs. Code Generator (für DB)

Erstellt von Snowwolf3000 vor 18 Jahren Letzter Beitrag vor 17 Jahren 2.502 Views
Snowwolf3000 Themenstarter:in
140 Beiträge seit 2004
vor 18 Jahren
O/R-Mapper vs. Code Generator (für DB)

Hallo,

wär dankbar wenn mir mal jemand die Vorteile und Nachteile von O/R-Mappern und Code Generatoren für Datenbanken definieren könnte.
Irgendwie bin ich nämlich etwas verwirrt: Also mit einen O/R Mapper (z.B. NHibernate) kann ich mithilfe eines Mapping-Datei (vorzugsweise in Xml geschrieben) auf Datenbank in Objektform zugreifen. Ein Code Generator wie myGeneration oder Codus erzeugt mir die Objekte und ich kann dann ebenfalls auf die Db in Objektform zugreifen. So und dann kann ich mir noch mit den Code Generator die Mapping Dateien für einen O/R-Mapper erzeugen lassen.

So und jetzt frag ich mich: Wann nehm ich nen O/R Mapper, wann nen Code Generator und wann erzeug ich mit nen Code Generator Quellcode für nen O/R-Mapper???

Gruß
Snowwolf

S
8.746 Beiträge seit 2005
vor 18 Jahren

Ein Codegenerator erzeugt aus einem relationalem DB-Schema eine objektorientierte Sicht. In der Regel bekommst du für jede Tabelle eine Klasse.

Das bedeutet aber auch, dass du für jede Beziehungstabelle eine Klasse bekommst (schlecht, weil nicht objektorientiert). Meist ist es auch nicht möglich, Abfragen abzusetzen, sondern du musst immer navigieren, was oft sehr teuer ist.

Ein O/R-Mapper ist wesentlich flexibler. Er erlaubt in die Abbildung einzusgreifen (wichtig um DB-Optimierungen ohne Änderungen am Objektmodell machen zu können), also z.B. Vererbung entsprechend abzubilden, Beziehungstabellen zu Objektbeziehungen zu machen, etc.! Meist werden wird auch Lazy Loading implementiert, also das Vorladen von ganzen Objektstrukturen bei Zugriff auf das obere Element. O/R-Mapper erlauben meist auch die Generierung des relationalen Schemas aus einem Objektmodell.

O/R-Mapper sind also deutlich mächtiger, aber natürlich auch komplexer zu handhaben.

Snowwolf3000 Themenstarter:in
140 Beiträge seit 2004
vor 18 Jahren

Danke svenson!
Habs verstanden. Das einzige was ich inzwischen echt nicht mehr verstehen kann ist, wie man ADO.net direkt einsetzn kann. Das Teil ist echt ne krankheit. 😉

S
8.746 Beiträge seit 2005
vor 18 Jahren

Wenn es darum geht SQL-Ergebnisse möglichst direkt an die Oberfläche zu werfen, ist ADO.NET schon ganz gut. Und das sind eben 90% aller Anwendungen, gerade im Web-Bereich.

Mit Objektorientierung hat das natürlich überhaupt nix zu tun. MS hatte diese Lücke ja erkannt und wollte selbst einen O/R-Mapper, bzw. eine objektorientierte Persistenzschicht .NET hinzufügen (Object Spaces sollte das wohl heissen). Das Projekt kann man als gestorben betrachten. Zum Glück gibts ja genug kommerzielle und Freeware-Alternativen. U.U. kann man sich auch überlegen, gleich mit einer OO-DB zu arbeiten. Da entfällt dann noch das ganze Mapping-Geraffel. Leider kritisch mit vielen Reporting-Tools.

F
97 Beiträge seit 2006
vor 17 Jahren

funktioniert ado.net auch mit windows anwendungen???

To Infinity and Beyond

1.373 Beiträge seit 2004
vor 17 Jahren

Ja sicher. ADO.NET ist ja (grob gesagt) lediglich für die Kommunikation mit der Datenbank und die verbindungslose Datenhaltung im Speicher (DataSets) zuständig. Wie du die Daten verwendest, ist egal. Datenbindung mit z.B. DataTables klappt sowohl mit WebForms als auch mit WinForms.

Grüße,
Andre

T
512 Beiträge seit 2006
vor 17 Jahren

Das einzige was mich an NHibernate stört und was ich einfach nicht verstehe ist, warum man log4net einsetzt.

Eine Bibliothek sollte nicht so ein Eigenleben führen, dass es seine eigenen Logdateien braucht. Was wo und wie gelogt wird, sollte immernoch der Benutzer der Bibliothek entscheiden.

e.f.q.

Aus Falschem folgt Beliebiges

3.728 Beiträge seit 2005
vor 17 Jahren

Original von Snowwolf3000
Habs verstanden. Das einzige was ich inzwischen echt nicht mehr verstehen kann ist, wie man ADO.net direkt einsetzn kann. Das Teil ist echt ne krankheit. 😉

DAO war eine Krankheit. ADO.NET ist genial. Mehr Komfort bei so viel Flexibilität gibts überhaupt nirgends sonst.

Direkt, im Sinne von "Immer wieder Connection, Commands und DataAdapter per Copy & Paste-Style hinzuschreiben" setzt man ADO.NET auch nicht ein. Man kapselt das. Das heißt aber nicht automatisch OR-Mapping.

Bei OR-Mapping würden die vielen Vorteile von DataSet/DataTable als flexiblen Datencontainer verloren gehen und dynamische SQL-Abfragen lassen sich in einem OR-Mapper gar nicht abbilden, da die kleinste Einheit ein ganzes Objekt ist. Wenn ich z.B. die Umsatzsteueridentnummer von Lieferant X brauche, muss ich bei einem OR-Mapper den kompletten Datensatz von Lieferant X übers Netzwerk jagen. Bei ADO.NET kann das ein parametrisierte Befehl erledigen, der genau einen Wert übergeben bekommt (ID von Lieferant X) und auch nur einen Wert als Ergebnis liefert (nämlich die Umsatzsteueridentnummer).

OR-Mapper sind für einige Anwendungsfälle super, aber für andere extrem mies. Bei komplexen Anwendungen steigt das Risiko, dass man einen Anwendunsfall abdecken muss, für den OR-Mapping extrem mies funktioniert. Mit ADO.NET kann man alles in Sachen Datenzugriff abbilden.

Ich bin mittlerweile der festen Überzeugung, dass OR-Mapper so häufig eingesetzt werden, damit man Projekte schnell abwicklen kann, ohne dass man Personal benötigt, welches über gutes Datenbank-Know-How verfügt. Aus betriebswirtschaftlicher Sicht ist das auch ein gutes Argument. Wenn es darum geht, hervorragende Software zu entwickeln, eher nicht (Ich will damit nicht sagen, dass alle, die für Ihre Projekte OR-Mapper einsetzen, unqualifiziert sind).

Was Code-Generatoren angeht, sag ich nur: Automatisiertes Copy&Paste.

S
8.746 Beiträge seit 2005
vor 17 Jahren

Original von Rainbird
Ich bin mittlerweile der festen Überzeugung, dass OR-Mapper so häufig eingesetzt werden, damit man Projekte schnell abwicklen kann, ohne dass man Personal benötigt, welches über gutes Datenbank-Know-How verfügt.

Das ist nicht von der Hand zu weisen. Zudem ist eben die Nutzung von ADO.NET eine vergleichsweise geschwätzige (und damit teure) Geschichte, gerade dann, wenn man sich erst noch nen DAL schreiben muss. Und für die meisten DB-Anwendungen sind ja die von dir genannte Kritikpunkte an O/R-Mappern angesichts läppischer Anforderungen nicht greifend. Insofern kann ich die Nutzung von O/R-Mappern schon gut nachvollziehen.

RDBMs passen aus technischer Sicht eigentlich nicht mehr in die Zeit. Insofern ist es schon nachvollziehbar, dass man sich den Gap, den man aus heutigen System zu überwinden hat um relational zu arbeiten, automatisch schliessen läßt. Aus meiner Sicht wäre es aber viel konsequenter gleich auf OO-DBs auszuweichen. Die Nachteile von O/R-Mappern entfallen, aber man nutzt zugleich die Produktivitätsvorteile, die immer gegen RDBMS stehen.

3.728 Beiträge seit 2005
vor 17 Jahren
geschwätzige Lösung

Warum soll ADO.NET geschwätziger sein, als ein OR-Mapper. Das versteh ich jetzt nicht so ganz.

S
8.746 Beiträge seit 2005
vor 17 Jahren

Original von Rainbird
Warum soll ADO.NET geschwätziger sein, als ein OR-Mapper. Das versteh ich jetzt nicht so ganz.

Nicht "als" sondern "mit". Die "Schlankheit" (bzw. die Menge) des (hangeschriebenen) Codes und der damit verbundene Produktivitätsgewinn ist doch i.d.R. der Hauptgrund für den Einsatz eines O/R-Mappers (oder einer OODB).