Wie ich im vorherigen Thread schon erwähnt habe, hat für mich Business-Logik nichts mit der Sprache zu tun.

Grundsätzlich sollte man (so weit es möglich ist) eine Trennung der Ebenen DB <--> Prozess/Business-Logik (damals PGM) <--> GUI ansetzen.
Ich schreibe Prozess statt PGM, da auch SQL Views dort hineinfallen können.

Eine View, die Daten entsprechend aufbereitet (z.B. Wechselkurs Berechnung, Erzeugung von JSON, usw.) gehört für mich hier in den Bereich "Prozess".
Diese View greift gleich wie alle anderen Prozesse/Programme auf die DB zu. (Am Besten via Views).

Man sollte also die Unterteilung der Ebenen nicht an eine Sprache festnageln sondern wofür es verwendet werden soll.

Am Ende des Tages geht es darum, dass man sich nicht selbst ein Loch gräbt.

Dieter Bender hatte damals bei der Common Europe in Wien einen Vortrag gehalten und von einem Projekt erzählt junger Entwickler, die XML als Schnittstelle für Programmaustausch (im Detail kann ich mich nicht mehr erinnern) einsetzten.
Er erzählte, dass diese Leute so gut wie alles falsch gemacht hatten, was man in der Zeit als "absolutes No-Go" abgestempelt hatte.
Dieses Design der Entwickler war jedoch modern, einfach erweiterbar, schnell und wartungsfreundlich.
Ein super Beispiel dafür, dass man "Regeln" immer wieder reflektieren, erweitern/ändern und an die aktuelle Technologie anpassen muss.
Dieses Beispiel fand ich sogar als das Wertvollste was man dort mitnehmen konnte, da es Zeitlos ist.