Oracle Application Express Tipps für Entwicklung und ... - Trivadis

Auditing Attribute
Jede Tabelle sollte Attribute besitzen, die pro Datensatz den Ersteller mit
Erstelldatum und den Editor mit Editdatum ausweisen. Das Füllen dieser vier
Spalten sollte über Before-Insert-Update-Trigger bewerkstelligt werden.
Grund:
� Änderungen an Daten können so einfacher nachvollzogen werden
� Der Audit passiert direkt in der Datenbank und muss nicht in der Anwendung
berücksichtigt werden
Geschäftslogik von Visualisierung trennen
Geschäftslogik und Berechnungen sollten unbedingt in der Datenbank, innerhalb
von Views, Triggers, Packages, Prozeduren und Funktionen, realisiert werden.
Wenn der PL/SQL Code keine GUI-Elemente enthält, kann er ohnehin vollständig
in die DB ausgelagert werden. Generell sollte so viel Geschäftslogik wie möglich in
die DB ausgelagert bzw. so wenig PL/SQL Code wie möglich in APEX hinterlassen
werden. Es sollten lediglich die für die Visualisierung notwendigen SQL Befehle
und Funktions- bzw. Prozeduraufrufe in der APEX Entwicklungsumgebung
gehalten werden.
Grund:
� Klassischer Ansatz der Software Entwicklung
� Einfacheres Debugging und Ressourcenkontrolle möglich
� Mehrfachverwendung von Code möglich (Modularisierung)
View-Schicht statt direkter Tabellenzugriff
Um einerseits die Vorteile der Wizard-getriebenen Entwicklung zu nutzen und
andererseits ein hohes Mass an Kontrolle über die DML Transaktionen zu
behalten, sollten sämtliche APEX-Formulare, in denen DML Operationen (Insert,
Update, Delete) vorkommen, ausschliesslich über Views auf die Daten zugreifen.
Die Implementierung der DML-Logik kann bei Bedarf (komplexe Views, komplexe
Updates etc.) in Instead-Of-Trigger verlagert werden. Diese Vorgehensweise ist
selbst dann empfehlenswert, wenn das APEX-Formular direkt nur auf eine einzige
View zugreift.
Oracle Application Express Tipps für Entwicklung und Betrieb 19