Livebindings Pro Contra

[Stevie]

Damit die DSharp Diskussionen nicht immer andere Threads verstopfen, hab ich mal einen Thread dafür eröffnet.

P.S. Der Delphi 2010 bug ist gefixt (patch für spring4d liegt im repository)

[mquadrat]

Zitat von neo4a:

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.

[neo4a]

Zitat von mquadrat:

Zitat von neo4a:

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.

Du hast mich da etwas aus dem Zusammenhang gequoted: Mir ging es nur darum zu zeigen, warum man eventuell bislang ganz gut auch ohne Binding auskommen konnte (ganz im Sinne des Thread-Titels).

BTW, gab es auch eine Reihe sehr guter Gründe, die Business-Logik in die DB zu verfrachten: Performance und konsistenter Daten-Zugriff bzw. Sicherheitsmodell und ein seinnerzeit noch sehr hoher Aufwand an Entwicklung und benötigter Hardware.

Zitat von mquadrat:

Zitat von neo4a:

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.

Fragt sich nur: Warum haben wir erst heute die Delphi-Tools und was machen wir hier alle überhaupt noch bei Delphi?

[mquadrat]

Zitat von neo4a:

Fragt sich nur: Warum haben wir erst heute die Delphi-Tools und was machen wir hier alle überhaupt noch bei Delphi?

Legacy-Anwendungen und Faulheit

[neo4a]

Zitat von mquadrat:

Zitat von neo4a:

Fragt sich nur: Warum haben wir erst heute die Delphi-Tools und was machen wir hier alle überhaupt noch bei Delphi?

Legacy-Anwendungen und Faulheit

Wessen Faulheit ist Schuld, dass es die nötigen Tools erst heutzutage gibt?! SCNR

[jobo]

OT:

Zitat von mquadrat:

Zitat von neo4a:

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.

Also die "Schwachsinns"-Formulierung halte ich für sehr unüberlegt.
Das Verfahren Business-Logik auf dem Server zu hinterlegen ensteht ja nicht aus dem Gedanken, Programmierparadigmen lupenrein umzusetzen.
Es geht schlicht um fehlerfreie und robuste Funktion. Und die hat berechtigterweise Vorrang gegenüber Clientprogrammierkonzepten.
Ein Server ist ein Server, selbst in einer Mehrschichtarchitektur, erst recht in einem sehr heterogenen System, find ich das sehr nutzbringend.
Natürlich sind durchgängige Programmiertechniken erstrebenswert, aber sie haben nicht den Stellenwert einer zentralen und robusten Businesslogik.

Hinzu kommen Performanceaspekte, die für eine direkte Implementierung auf dem Server sprechen, deren Bedeutung allerdings je nach Last des Systems oft hinten angestellt werden können.

Eine leistungsfähige SQL- und Datenbankprogrammiersprache sind dafür natürlich ebenfalls wünschenswert. Aber das ist ja heute auch kein Thema mehr.

[hanspeter]

Bussines-Logik auf dem Server als Schwachsinn zu bezeichnen, halte ich auch für zumindest gewagt.
Technologien wie z.B. SOAP unterstützen die serverseitige Programmierung.
Wer sagt, das auf der Serverseite auf objectorientierte Programmierung verzichtet werden muss?
Wir verwenden stored procedure nur um einen Serverprozess zu starten und mit Parametern zu versorgen.
Moderne SQL Server lassen die Erstellung von SP mit beliebigen Programmiersprachen zu. (Firebird ab 3.0)
Wir nutzen die Technologie um auf den Server einen Verarbeitungsjob zu starten, der dann die eigentliche Verarbeitung vornimmt.
Der von der Datenbank aktivierte Steuerjob ist in der Lage Verarbeitungsprozesse mehrfach zu starten und auf eigene Threads zu verteilen.
Keine Oberfläche - im Eingang nur Datensätze aus der Datenbank und ausgangsseitig nur neue/modifizierte Datensätze in der Datenbank, da läßt sich der Test weitestgehend automatisieren.

Gruß
Peter

[mquadrat]

Ich habe nie behauptet, dass Business-Logik auf einem Server Schwachsinn wäre. Ich sagt, dass meiner Meinung nach Business-Logik komplett über StoredProcs zu fahren Schwachsinn ist. Auch wenn man die Möglichkeit hat UDFs in einer OOP-Sprache zu schreiben bleibt die Aufgabe des DB-Servers nun mal das Verwalten von Daten. Möchte ich einen App-Server dann spricht ja nichts dagegen einen echten App-Server einzusetzen. Also z.B. Tomcat, AppFabric oder was auch immer. Aber ein DBMS Zweck entfremden?