ORM - wieweit sinnvoll?

[stahli]

Ich konnte mir bezüglich ORM noch keine klare Meinung bilden und will mal gern etwas grundsätlicher über ORM diskutieren...

Das Ziel ist doch, dass man mit klassischen Objekten arbeiten kann, die die Daten + Geschäftslogik beinhalten.

Für große Datenmengen will man jedoch eine Datenbank benutzen, da nicht alles in den Hauptspeicher passt. (Eine komplette DB-Anwendung mit der Geschäftslogik in Store Procedures usw. ist jedoch nicht jedermanns Sache, weshalb mit Objekten gearbeitet werden soll.)

Nun stellen sich einige allgemeine Fragen:
- Wie kann ich komfortabel meine "Datenklassen" erstellen? (vielleicht sogar mit grafischer Unterstützung für die Definition der Beziehungen?)
- Wie kann ich in den Klassen flexibel meine Geschäftslogik implementieren?
- Wie kann ich auf die Objekte zur Laufzeit verwenden (linq to objects)?
- Wie greife ich aus der GUI auf die Daten zu?

Und einige Zur Speicherung:
- Wie kann ich die Objekte in eine DB speichern?
- Will ich direkt per SQL auf die DB zugreifen?
- Wie realisiere ich die Anbindung mehrerer Clients?


Für die Erzeugung der Datenklassen kann ich mir nichts besseres als einen Codegenerator vorstellen. Der nimmt einem die Tipperei ab und man erhält Units, in die man seine Geschäftslogik (also alle Berechnungen etc.) implementieren kann.

Das Filtern von Objekten ist im Moment noch schwierig. Daniela hat einen Linq-Ansatz vorgestellt (habe ich noch nicht konkret getestet), der sehr interessant klingt. Alternativ muss man Funktionen schreiben, die z.B. alle TKunden-Objekte suchen, welche etwa mit "A" anfangen und diese in einer Liste zurück geben.

Für die Benutzung der Daten in den Formularen gibt es inzwischen die Möglichkeiten der Datenbindung.


Bis hierher ist kein OR-Mapper notwendig. Ich habe Objekte, die Daten und die Geschäftslogik beinhalten und einander referenzieren können.
Wenn keine extrem großen Datenmengen zu verwalten sind, kann man das ganze Geraffel einfach im Speicher halten und nachher in eine XML-Datei oder was auch immer speichern.

Hier macht es noch keinen Sinn, die Daten in eine SQL-Datenbank zu pressen, oder seht Ihr das schon anders?


Anders sieht es aus, wenn wir große Datenmangen haben.

Klassische DB-Anwendungen (wie z.B. Sparkassenkonten) werden wohl auch immer als reine DB-Anwendung realisiert werden. Da ist wohl auch keine sehr komplizierte Geschäftslogik zu erwarten, die man unbedingt mit Objekten realisieren will. Soweit dakor?

Also nehmen wir mal ein anderes Projekt: Ahnenforschung oder so.
Die Personen und Beziehungen lassen sich ja perfekt in Objekten abbilden.
Damit es etwas komplexer wird, wollen wir auch noch die Fahrzeuge (Auto, Motorrad, Fahrrad) der Personen verwalten sowie deren ganzen Immobilien ).


Jetzt stellt sich die Frage, wie die Datenbank aufgebaut werden soll.
Jeweils eine Tabelle für Personen, Fahrzeuge und Immbilien? Die Verbindung über Schlüsselfelder?
Bei Änderungen der Datenstrukturen müssen die Objekte und die ganzen Tabellen angepasst werden. Vorhandene Datenbanken müssen mit komplexen Skripten angepasst werden.

Ein guter OR-Mapper sollte die Diff-Scripte automatisch erzeugen - richtig? Gelingt das aber immer und zuverlässig? Muss man händische Anpassungen vornehmen?

Dieser Aufwand würde m.E. nur Sinn machen, wenn man auch direkt in die DB greift und dort Daten abruft (z.B. alle Fahrzeuge der Personen mit "A") oder ändert. Hat man aber vor, immer über die Objekte zu gehen, macht aus meiner Sicht eine einfache Tabelle Sinn, die lediglich die ObjectId, PropName, PropValue als reinen Datenspeicher enthält (zusätzlich muss natürlich auch noch die Baum-Struktur der Objekte gespeichert werden).

Die Tabelle bleibt dann gleich, auch wenn neue Klassen eingeführt werden.
Der Nachteil ist, dass PropValue als Text gespeichert (und dann zur Laufzeit umgewandelt) werden müsste und dass keine Indizes und Joins bei Abfragen verwendet werden könnten.

Der Versuch, die Tabellen möglichst genau an die Objektstrukturen anzupassen, führt m.E. eher zu Problemen als zu Nutzen - jedenfalls wenn man letztlich doch nur mit den Objekten arbeiten will.

Eine Teilung der Zuständigkeiten (manches über Objekte regeln, aber auch direkt auf die DB zugreifen) halte ich für keine sinnvolle Lösung.


Wenn man das so sieht wie ich (ich höre gern auch andere Meinungen), macht es wenig Sinn, sich über einen ORM viele Gedanken zu machen. Die Vorteile einer relationalen Datenbank reizt man dann ja ohnehin nicht aus - gewinnt aber statt dessen die flexiblen Möglichkeiten der OOP.

Also arbeite ich dann einfach mit meinen Objekten. PUNKT.
Ob die ihre Daten nun im Hauptspeicher halten oder auf Grund der Menge in einer einfachen Tabelle als Zwischenspeicher ablegen, ist dabei im Grunde unerheblich.
Natürlich ist es sinnvoll, eine Art Pool zu verwalten, so dass Objekte erzeugte Objekte nicht sofort wieder verworfen werden, falls man noch einmal darauf zugreifen muss.

Die Objekte bilden eine Gruppe von Daten, Geschäftslogik und Beziehungen und sind ineinander gekapselt.

Über die Modenen Möglichkeiten der Datenbindung können die Formulare und Controls an die Daten gebunden werden, so dass man quasi User-Schnittstellen nach außen hat.

Für kleinere Projekte können die Daten im Hauptspeicher liegen, für größere in einer Datenbank (als "Datenlager").


Der grundsätzliche Nachteil ist natürlich, dass man bei einer "Suche aller Fahrzeuge von Personen mit "A") erst einmal alle Personenobjekte untersuchen (ggf. vorher erzeugen) muss um dann ggf. die Fahrzeuge in eine Liste zu schreiben. Das ist natürlich nicht die schnellste Lösung und das Erstellen eines evtl. Reports ist etwas aufwendiger als bei einem DataSet als Ergebnis.
(An der Stelle stößt mir dann immer der Vorteil der SQL-DB auf - aber diesen Ansatz hatten wir ja schon verworfen).


Ok, dafür dass ich komfortabel mit OOP arbeiten kann, nehme ich die genannten Nachteile in Kauf.


Einen Grund für einen vollständigen ORM sehe ich aber immer noch nicht. Die Vorteile, die SQL-Datenbanken bieten, kann ich ja ohnehin nicht ausreizen. Oder gibt es ORM, die das wirklich schaffen und trotzdem flexible Änderungen der Datenstrukturen und der Geschäftslogik zulassen?
M.E. nicht. (Ich würde mich aber gern eines besseren belehren lassen.)



Nun stellt sich die Frage nach Client-Server-Lösungen.
Hier würde ich mir vorstellen, dass es einen "Server" gibt, der die Datenobjekte erzeugt und bereitstellt.
Die "Clients" könnten reine GUI-Anwendungen sein, die bestimmte Controls zur Darstellung und Bearbeitung von Daten beinhalten. Wenn diese Controls sich darstellen müssen (also wenn sie gezeichnet werden), würden sie vom Server ihren "Wert" abrufen (z.B. für ObjId='12345", PropName='FirstName'). Die Datenbindung würde dann sozusagen über ein Netzwerk erfolgen.
Wie über diesen Weg Methoden der Geschäftslogik angestoßen werden können ist mir jedoch noch nicht klar.


In Bezug auf ORM-Lösungen habe ich jedoch immer wieder Zweifel, ob diese wirklich zielführend sind. Eine wirklich gute Lösung scheint es ja auch nicht zu geben.
Entwender ist das Handling sehr aufwendig und unflexibel oder die ganze Lösung nicht stabil verwendbar.


Wie seht Ihr das Thema?

[mquadrat]

Du fasst den Begriff ORM zu weit. Wie du die Klassen erstellt, wie du deine Geschäftslogik entwirfst und wie die Daten eigentlich in die GUI kommen ist nicht Aufgabe des ORM. Der ORM dient nur dazu Daten aus der DB in die Klassen zu bekommen und umgekehrt. Da ein ORM gerade kein Active-Record Pattern umsetzt gibt es auch keine Notwendigkeit für eine 1:1 Beziehung zwischen Klassen und Tabellen (auch wenn dieses Automapping erlauben würde).

EDIT: Zum Thema Tabelle laden und im Speicher halten: Schon mal 5.000.000 Datensätze in den Speicher geladen, mit anderen Daten verknüpft und dann komplexe Suchanfragen gemacht?

EDIT2: Auch Diff von Tabellenstrukturen ist keine Kern-Aufgabe des ORM, sondern des Change Management.

[Phoenix]

ORM sind immer dann Sinnvoll, wenn Du wirklich mit Objekten arbeiten kannst / willst / musst, und die Einschränkungen der Mapper hinnehmen kannst / magst / sie Dich nicht stören.

Zudem erkauft man sich Objektrelationales Mapping immer mit Einbussen.
1.) OR-Mapper sind immer darauf ausgelegt, das darunterliegende RDBMS austauschbar zu halten. Das heisst sie abstrahieren auf einen gemeinsamen Nenner und meistens gehen dabei DBMS-Spezifische Spezialfeatures flöten, an die man einfach nicht ran kommt.
2.) Performance. Das ganze hin- und hergemappe und die Generierung der Statements kosten nunmal CPU-Zyklen und damit Zeit.
3.) Medienbruch. Die meisten ORM generieren Dir aus der Datenbank Klassen die Du benutzt. Du musst jedoch weiterhin in der DB die Strukturen anpassen und dann die Klassen neu generieren. In Sprachen die Partial Classes unterstützten ist das nicht so ganz wild, weil hier dann eine Datei generiert wird und Deine selbst implementierte Logik in einer anderen Quellcodedatei liegt. Da Delphi das nicht kann muss hier mit Ableitungen gearbeitet werden, was die Sache nochmal unschöner macht. Ein gutes Zwei-Wege Systeme ist mir (leide?) noch nie über den Weg gelaufen.

In einer Entwicklungsumgebung wie Delphi, wo die Datenverarbeitung aber (noch) von Grund auf auf Tabellen basiert (TTable, Datengebundene Controls die Du nur an solche Komponenten binden kannst) macht das ganze keinen wirklichen Sinn, denn da kann man genauso gut Daten- und Tabellenbasiert mit arbeiten und kann auf den ganzen Objekt-Overhead verzichten.

Andere Umgebungen wie .NET, wo man auch am UI nahezu alles mit Objektbasiertem Databinding erledigen kann, oder bei Umgebungen die eh nicht viel mit UI zu tun haben (Backendsysteme in Java / .NET), sieht die Sache dann wieder anders aus. Hier ist man eher bereit, den Mapping-Overhead in Kauf zu nehmen um sich den ganzen DB-Quatsch zumindest im Code vom Hals zu halten, und da macht das dann auch deutlich mehr Sinn.

Aus dem Grund basiert DataAbstract für Delphi ja z.B. auch auf Tabellen im Client und bietet hier kein OO-Interface an, wobei die .NET Version hier mit DALinq auch Objekte anbietet, auf denen man arbeiten kann.

[stahli]

@mquadrat

Ok, ich war immer davon ausgegangen, dass ECO ein Beispiel für einen ORM ist. Aber dann ist ECO offenbar viel mehr.
Dann gibt es wohl noch weniger Gründe, in Richtung ORM zu denken.
Natürlich ist eine Funktionalität notwendig, die Felder einer Datenbank zu benutzen, aber das ist ja nur ein kleiner Teil eines Frameworks, mit dem der Programmierer arbeiten will.

Wenn ich Klassen von Hand erstelle kann ich auch vorgeben, wo diese ihre Daten speichern soll.

Eine komfortable Arbeitsweise verstehe ich eben gerade nicht darunter...


@Phoenix

Super Erklärung - Danke dafür

Delphi bräuchte neben LinqToObjects offenbar dann noch "partial classes" (das würde auch meinem Codegenerator gut tun ) und "cross units", um mit .net gleich zu ziehen
Für das Databinding gibt es ja nun schon Lösungen.

Zitat:

Aus dem Grund basiert DataAbstract für Delphi ja z.B. auch auf Tabellen im Client

Offenbar konnte ich Deine früheren Hinweise deshalb noch nicht genauer für meine Zwecke einordnen...

[webcss]

@phoenix:
wenn ich Dich richtig verstehe, rätst Du also von der Nutzung eines ORM ala tiObjects oder ähnliche unter ObjectPascal ab.
Natürlich ist es richtig, dass die Systeme nicht zusammenpassen (Stichwort Impedance Missmatch), aber andereseits hör ich immer klagende Aufschreie, wenn es um die Nutzung von DataAware VCL geht...

Wie macht man es denn jetzt richtig, für eine Standard-Anwendung (Warenwirtschaft o.ä.)?

Mittlerweile bin ich total durcheinander, denn letztendlich wollen ja die meisten von uns wartbare und zukunftsichere Programme schreiben...

Bitte um Klärung

[Lemmy]

Hi,

es kommt halt drauf an... Wenn schon von vornherein klar ist, dass unterschiedliche DBMS angebunden werden sollen und eine gewisse Geschäftslogik abgebildet werden soll, dann würde das schon stark für ein (großes) ORM sprechen, da die GEschäftslogik innerhalb des ORM wäre und die DBMS nur als austauschbare Datenspeicher dienen.

Andererseits ich habe mir mal selbst ein einfaches ORM geschrieben für ein Programm, das Daten für Energiepässe berechnet hat. Die Berechnungen wurden auf einem Objektmodell durchgeführt, dessen Daten in einer XML-Datei gespeichert wurden. Für solche Zwecke würde ich niemals ein fertiges ORM einsezten, viel zu viel Overhead und zu wenig Freiheiten um die projektspezifischen Dinge abbilden zu können.

Genauso würde ich es mir zweimal überlegen, wenn ich ein Warenwirtschaftsprogramm erstellen würde, wo von vorn herein klar ist, dass nur eine bestimmte DB eingesetzt wird. Hier würde ich ggf. ein leichtes ORM produzieren (Delphi bringt hier ja alles notwendige mit) um die einzelnen Elemente gut gegeneinander kapseln zu können (Adressverwaltung, Inventar, Rechnungsschreibung) damit hier definierte Schnittstellen existieren. Sollte dann im laufenden Betrieb dann doch die Anforderung kommen ein weiteres DBMS unterstützen zu müssen, könnte man das relativ weit unten in der Hierarchie ohne dass das OM davon betroffen ist entsprechend einpflegen. Denn wenn schon ein Objektmodell da ist bzw. gebraucht wird, ist das Mapping gegen eine DB nur noch ein kleiner SChritt. Und hier ist es schon entscheidend, ob das RM aus 20-30 Zeilen Code besteht oder für jede Klasse 20-30 Zeile Code notwendig sind!
und ein weiterer unschätzbarer Vorteil ist die Möglichkeit das ganze per Unit-Tests abzusichern - versuch das mal bei einer Anwendung mit DBEdits die direkt auf einer Query hängen.

Dennoch sollte man nicht den Pflegeaufwand für ein eigenes ORM unterschätzen. Fehlentscheidungen können hier mal ganz schnell ein paar Tage/Wochen Entwicklungszeit kosten bzw. die eigentlich erhoffte Beschleunigung der Entwicklung durch ein schlechtes Klassenmodell bzw. zu starken Abhängigkeiten mal ganz schnell auffressen.

[mquadrat]

Ich persönlich bevorzuge ORM "light". Hauptaufgabe ist bei mir CRUD (ich hasse dieses sinnlose Query-Geschreibe). Navigational Properties oder automatisches Vererbungshandling treten bei mir eher in den Hintergrund.