Es ist noch gar nicht soo lange her, da wurde gefordert, dass die gesamte Business-Logik in die Datenbank gehört (über Trigger, StoredProc).
Also das war in meinen Augen - mit Verlaub - schon immer eine schwachsinnige Idee. Man verwendet eine objekt-orientierte Sprache um die Business Logik dann prozedural in einem RDBMS zu schreiben, das für sowas gar nicht gedacht ist?! StoredProcs taugen m.A. nach nur für's Number Crunching wenn das hin- und her der Daten den Ablauf nur verlangsamen würde.
Zitat:
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.
Der Ansatz war vielleicht vor 10 Jahren ausreichend. Spätestens mit dem Aufkommen von service-orientierten Architekturen war der überholt. Delphi war immer "aus einem Guß" und genau das dürfte hier das Problem gewesen sein. Java und .NET besteht aus vielen einzelnen Gruppen, die miteinander kommunizieren müssen. Somit ist das Prinzip der losen Kopplung dort eine Notwendigkeit aus der Struktur heraus. Gerade bei Java macht das vieles komplizierter, aber es erzwingt auch sich Gedanken für "moderne" Programmierung machen zu müsesen.
Zitat:
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.
Dem ist nichts hinzuzufügen
Für Anfänger aber sicher die Hölle
Da lernt man ja meistens erstmal, dass Objekte / Klassen reale Elemente abbilden (das Fahrzeug <-> Auto Beispiel, kennt wohl jeder Anfänger). Inzwischen sind wir schon eine oder zwei Ebenen abstrakter.