ORM - wieweit sinnvoll?

[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.