Businesslogik in die Applikations oder in die DB-Schicht?

[fanderlf]

Dazu haben wir wohl etwas zu wenig Informationen vom OP

[Walter86]

Hallo zusammen,

um mal grob darzustellen was für Bedingungen und Pläne wir haben:
- gleichzeitig zwischen 2 und 200 Benutzer
- bisher waren wir Datenbankagnostisch, was aufgrund der aktuellen Programmiersprache aber immer auch aufwendiges Query-Umschreiben hies
- wichtig ist auch dass die Benutzer ein schnelles Feedback bekommen (wobei sich das mit den Nertzwerkantwortzeiten auch etwas relativiert)

- Es soll eine Art von Workflowengine eingesetzt um die Benutzerabläufe konfigurieren zu können (BPEL oder ähnliches)
- Einzelne Schritte im Workflowprozess können von sehr einfachen Validierungen bis zu komplexen Lagerstrategie-Entscheidungen reichen (wohin bring ich das Material, von wo hol ich das Material, Kapazitätsberechnungen, Reservationshandling)
- Generell soll das ganze seeeeeehr konfigurierbar sein um die sehr verschiedenen Kundenbedürfnisse möglichst ohne viel neuem Code abdecken zu können (Wiederverwendbarkeit ist klar eines unseren grössten Themen bei dem Projekt)
- Ebenso ist aus den aktuellen Erfahrungen heraus die Testbarkeit (Unit-Tests, Regressionstests, etc) eines der Hauptthemen


Marketingtechnisch kann man ja beide Varianten gut verkaufen:
- Eine feste DB => Appliancelösung die Kundenunabhängig ist
- Flexible DB => Anpassung an vorhandene Infrastruktur / Firmenpolitik was benutzt werden soll ("Wir wollen alles im MS Umfeld haben" zum Beispiel)

Danke schonmal für all die bisherigen Antworten
Walter

[fanderlf]

...Wiederverwendbarkeit ist klar eines unseren grössten Themen bei dem Projekt...

Heutzutage wird Verwendbarkeit schon stark angezweifelt. Die Theorie ist zwar toll, aber in der Praxis scheint es nicht zu bewähren. Seid vorsichtig dass ihr nicht zu früh mit verallgemeinerung anfangt. Allgemein wird dieses Phänomen als "premature generalisation" bezeichnet. Analog dazu gibt es auch noch "premature optimisation". Dazu findet sich auch einiges auf google

Generell geht es darum Code primär auf Wart- und Lesbarkeit zu trimmen. Zu komplexe Frameworks die für "falls wir mal..." entworfen werden, leiden meist darunter nicht mehr gut Wart- und Lesbar zu sein.

Also passt an dieser Stelle auf. Immer nur soviel programmieren, dass die Arbeit erledigt ist. Aufpassen muss man immer bei "Falls ich aber irgendwann mal...", das ist generell immer zu viel Arbeit.

[gfoidl]

Hallo,

ich kann Florian nur zustimmen und in dem Punkt

Generell geht es darum Code primär auf Wart- und Lesbarkeit zu trimmen.

noch um Testbarkeit ergänzen.

Das bis ins Detail vorausplanen was einmal gebraucht werden kann oder nicht bringt i.d.R. nicht viel denn es kommt eh anders als gedacht. Besser ist es hier - ganz nach dem Prinzipien der OOP - offen für Erweiterungen zu sein. Dieses Ziel lässt sich relativ einfach mit gutem testbaren Code erreichen und später können kundenspezifische Features zB über Plug-Ins auch nachgereicht werden (DI ist Voraussetzung dafür).

Aber wir schweifen in der Diskussion schon ganz schön vom Titel des Themas ab...


mfG Gü

[architect_01]

Warum wird dieses Thema eigentlich immer so religiös und absolut betrachtet ?

record locks, indices, views, functions, strored procedures, triggers, constraints, primary/foreign keys, commit, rollback, grant, revoke, clustering/partitioning, ...
... das sind doch nicht alles Erfindungen einer geldgierigen DB-Mafia (IBM, Oracle,
Microsoft, Sybase, ... ), die damit die reine Persistierung von Geschäftsdaten nur
etwas aufhübschen will.
Das sind Tools zur Gewährleistung von Security, Intgegrity, Concurrency und Performance, die man immer auch sinnvoll in Applikationen integrieren kann.
Zur Versionsverwaltung kann man da den "Quellcode" praktisch einfach mit in
die Filesystemstruktur der restlichen Applikations-Sourcen integrieren.
z.B. methode.sql (hier entspricht dann eben execute praktisch dem compile):
CREATE OR REPLACE FUNCTION simple RETURN VARCHAR2 IS
BEGIN
RETURN 'Version 1';
END;

Ich sehe da auch absolut gar kein Konfliktpotential zu OOP-Prinzipien.
Es wird immer Code für Setter und Getter von Properties für Objekte geschrieben
werden müssen. Dabei wird dann auch immer ein gewisses Mass an
Exception-Handling erforderlich sein. Der einzige Unterschied zwischen den
Varianten ist doch nur, ob die DB dabei quasi die anderen Objekt-Methoden zusätzlich mit absichert (d.h. u.u. bereits selbst eine bzw. die Exception wirft)
und die dafür in ihr gespeicherten Informationen zur Verbesserung der Performance
nutzen darf.
Die Businesslogik spielt sich dabei auf der höheren Abstraktionsebene immer in der Applikation ab, aber die Auslagerung der Module auf der niederen Ebene erhöht
nicht nur die Übersichtlichkeit sondern sichert dadurch dann sogar zusätzlich
z.B. externe Schnittstellen bzw. Eingriffe ab.
Natürlich ist das keine Garantie für Qualität - Fehler werden vermutlich immer mal gemacht.
Trotz der Erfindung des Airbags schnalle ich mich aber weiterhin an.
Das handhabe ich genau wie dieses Thema nicht als Entweder-Oder-Lösung.

[Ralf Jansen]

Ich sehe da auch absolut gar kein Konfliktpotential zu OOP-Prinzipien.

Religiös gesehen ich schon. Aber a) bin ich da sowieso eher agnostisch veranlagt b) ist die Diskussion fruchtlos da alle Beteiligten vermutlich in etwa gleich denken mit nur graduellen Unterschieden die wir nur gepflegt ausarbeiten könnten und c.) dann wenn es in dieser Richtung doch Interessant werden könnte die Admin-OffTopic-Keule droht