Es ist noch gar nicht soo lange her, da wurde gefordert, dass die gesamte Business-Logik in die Datenbank gehört (über Trigger, StoredProc). Arbeitete man nur mit
DB-aware Controls, brauchte es auch keine Bindings.
Es kommt für mich gar nicht überraschend, dass (Live)Bindings erst jetzt bei Delphi ankommen, weil vor allem die spezielle Konstruktion der VgScene/FMX-Controls eine statische
DB-Awarness unsinnig machen (VgScene als Vorläufer der FMX kennt auch deshalb schon Bindings). Zuvor war der Delphi-
RAD-Ansatz mit
VCL-
DB-Controls völlig ausreichend und wir alle haben damit ja auch großartige Apps geschrieben. Und so hätte es auch bleiben können.
Will man aber nun mehrere Plattformen unterstützen oder einfach nur die schicken FMX-Controls nutzen und/oder testbaren Code schreiben und mit Mockups testen, dann kommt man mit den Alt-Ansatz allerdings nicht mehr so weit.
Mit DSharp-Bindings kann man sich sein Entwicklerleben schon erleichtern. Mit DI-Containern wie Spring4Delphi kann man herrlich modularisieren. Und wenn man (wie N.Hodge es fordert) nur noch gegen Interfaces programmiert und die Klassen-Definitionen nur noch im Implementation-Teil der
Unit unterbringt, ist man schon ganz modern dabei.
Das alles ist nur noch zu toppen, durch ein MVVM-Ansatz. Die seit heute in DSharp verfügbaren Demos lassen einen schon ahnen, wohin die Reise geht. Da ist - dank Konventions-Logik - kaum noch Code in den Views und selbst in den nichtvisuellen Komponenten passiert nichts mehr. Allein durch die Benennung wird alles automatisch zusammen "geklickt". Ziemlich cool.