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
![Wink](images/smilies/icon_wink.gif)
).
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?