Meiner bescheidenen Meinung nach werden hier einige Dinge durcheinander gewürfelt...
Ein ORM wird ja genutzt, um die Businesslogik mit Objekten zu realisieren (das ist für die Realisierung der Logik und Abläufe schön übersichtlich und vom Handling her einfach), die Daten aber in einer relationalen Datenbank zu halten (dies ermöglichst eine gute Strukturierung der Datenverwaltung incl. Joins usw).
Der ORM ist der Vermittler beider Welten.
Als Programmierer der Anwendung bezieht man sich im Grunde nur noch auf die Objekte. Wie die an ihre Daten kommen ist dabei nicht relevant.
(Natürlich muss das auch realisiert werden und es gibt verschiedene Ansätze und Tools dafür, aber für die eigentliche Anwendung spielt das keine Rolle.)
Wenn ich mit Objekten arbeite, kann ich beliebige Eigenschaften mit und ohne Setter und Getter definieren. Ich kann also (rein technisch gesehen) einen Setter set_Gesamtpreis einrichten, der intern irgendwelche Einzelpreise und Mengen zuweist.
Man müsste dann entscheiden, was in die Datenbank geschrieben wird... Nur der zugewiesene Gesamtpreis? Sicher nicht. Der Gesamtpreis und die berechneten Details? Sicher auch nicht. Also nur die Einzelpreise und Mengen. Der Gesamtpreis wird dann für die Rechnungslegung neu aus den Einzelposten berechnet.
Insofern reduziert sich set_Gesamtpreis auf eine Prozedur zur Festsetzung anderer Werte. Man könnte die Methode also auch als Prozedur regeln, die nicht als Setter fungiert (CalcDetailsForPrice).
Ein berechnetes Feld einer Datenmenge könnte das natürlich nicht. Dazu bräuchte man eine store procedure oder entsprechende update Statements.
Berechente Felder könnten nur einen Gesamtpreis aus Einzelpreis und Menge berechnen.
Das hat aber eigentlich nichts mit ORM oder LiveBindings zu tun.
Man konnte schon mit Delphi1 Klassen definieren, die ihre Feldwerte in Datenbanken schreiben oder daraus lesen. Das war etwas aufwendig, da man die Funktionalität für jedes Feld einzeln ausführen musste.
Mit der neuen
RTTI ab Delphi 2010 kann man Klassen aber nun untersuchen und z.B. alle Propertys in einer Liste durchlaufen, Namen und Typ ermitteln und davon abhängig Daten zwischen Objekten und Tabellen übertragen.
Es können somit beliebige Objekte an eine solche Funktion übertragen werden, wobei die Funktion dann selbständig entscheidet, welche Daten wie übertragen werden können und müssen.
Später kann ich auch neue Klassen definieren und die entsprechenden Objekte zusätzlich übergeben, ohne mich um die Struktur der Objekte kümmen zu müssen (Stichwort Serialisierung).
Im Grunde erspart das aber "nur" Schreibarbeit, die man sonst für jede Klasse zusätzlich vornehmen müsste (ähnlich dem Wegfall eines Cast bei den Generics).
Das LiveBinding (bzw. DSharp oder odControls
) ist noch eine andere Nummer. Hier geht es darum, die Daten im Formular zu präsentieren und dem Endnutzer eine Bearbeitung zu ermöglichen.
Klassisch würde man EditPerson.Text := MyPerson.Firstname schreiben und beim speichern die andere Richtung gehen.
Ein Databinding soll diese Arbeit (GlueCode) abnehmen. Man sagt einfach dem Edit (zur Designtime), welche Daten es anzeigen soll und ein Framework kümmert sich zur Laufzeit (mehr oder weniger gut), dass das auch so gemacht wird. Es überträgt also die Daten zwischen Objekt (oder DataSet) und
GUI, ohne dass man dies im Quelltext selbst veranlassen muss.
Jetzt bin ich mal gespannt...