Livebindings Pro Contra

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