OT:
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.