Oracle APEX: Fortgeschrittene Techniken aus der Praxis => Design Patrick Wolf – Denes Kubicek - Dietmar Aust 17.03.2008 – 19.03.2008

Oracle APEX: Fortgeschrittene Techniken aus der Praxis

=> Design Patrick Wolf – Denes Kubicek - Dietmar Aust

17.03.2008 – 19.03.2008

Seite 2

Oracle APEX: Fortgeschrittene Techniken aus der PraxisPatrick Wolf – Denes Kubicek – Dietmar Aust

Agenda

Datenmodell

Geschäftslogik

Konfigdaten

Parsing Schema

Workspace

Applikationsaufteilung

Seitennummerierung/-gruppierung

APEX Einstellungen

Teamentwicklung

Seite 3


Datenmodell

Zeit investieren!

Seite 4


Datenmodell

Datenmodell leben länger als Applikationen

Ist letztes Bollwerk für konsistente Daten

Seite 5


Datenmodell – Grafisch visualisieren

ERDs oder UML Diagramme

Farben verwenden

Logisch Gruppieren

Von Oben nach Unten

Hilft beim Denken

Leichterer Einstieg für neue Entwickler

Man diskutiert ganz anders

Seite 6


PROD ORDER PART GROUP# SEQo SHEET_LENGTHo SHEET_WIDTHo GUILLOTINEo HOLEo SHEETS_PER_REAMo IS_LANDSCAPE

LABEL PRODUCTIONo PRINT_DATETIMEo PRODUCTION_DATETIMEo PRODUCTION_QUANTITY

MATERIAL TYPE...

PAPER PRODUCT...

PRODUCTION ORDER STEP# SEQo NASCO_PRODUCTION_STEP_NO

PRODUCTION ORDER PART# SEQo GROUP_SEQ* CONTROL_ID...

PRODUCTION PLAN# PLAN_NOo PLANNED_WEIGHT* IS_LABEL_TO_BE_CHECKED* IS_IN_PRODUCTION* IS_FIX_PLANNED_BEGINo PLANNED_BEGIN_DATETIMEo PLANNED_SETUP_DURATIONo PLANNED_DOWNTIME_DURATIONo PLANNED_DURATION...

MATERIAL...

PRODUCTION ORDER# ORDER_NO* NASCO_CUSTOMER_NO* NASCO_CUSTOMER_NAME...

.

.

.

.

LABEL

.

.

.

.

.

.

.

.

BOXLABEL

.

OUTPUT

.

INVENTORY

.

GLUELPAL

.

REAMLABEL

.

.

.

.

.

.

.

Seite 7


Datenmodell

Künstlicher Primary Key (mit Sequence) In APEX maximal 2 Primary Key Attribute Update auf natürlichen „Primary Key“ keine Auswirkungen Eine Sequence reicht Nachteil

− Eventuell mehr Joins

− Constraints können weniger überprüfen

Unique Keys verwenden! Jede Tabelle hat meistens natürlichen Schlüssel!

(Auftragsnr., Kundennr, Auftragsnr.+Position, …) Wenige Ausnahmen (Logging Tabelle, ...)

Seite 8


Datenmodell

Foreign Keys verwenden! Schaft Sicherheit und konsistente Daten Nicht auf Applikation verlassen!!! Performance schon lange kein Thema mehr Foreign Key Spalten generell indizieren

− Schneller beim joinen

− Verhindert Table Locks

Konsistentes Namensschema überlegen Keine Lookup Tabellen sparen!

− Z.B.: für Aufzählungen (E-Mail, Fax, Tel, ...)

Seite 9


Datenmodell – Keine Lookup Tabellen sparen

Mehr Stellen zeigen Werte an als man denkt!

Zu viele Lookup Tabellen?

Generische Tabelle als Alternative DOMAIN (z.B.: KOMMUNIKATION) DOMAIN_VALUE (z.B.: TEL, FAX, E-MAIL, ...)

Seite 10


Datenmodell – Generische Werteliste

Seite 11


Datenmodell – Generische Werteliste

Vorteile Eine generische Maske zum pflegen aller Werte Keine Datenmodell Änderung notwendig „Spart“ viele Tabellen

Nachteile Weniger Aussagekraft von Foreign Key Constraints FK kann nicht auf bestimmte DOMAIN überprüfen CBO hat weniger Information

Seite 12


Datenmodell

Check Constraints verwenden! Schaft Sicherheit und konsistente Daten Nicht auf Applikation verlassen!!! CBO hat mehr Informationen

NOT NULL Constraints verwenden Gehört zum Analyse/Design Prozess

Seite 13


Datenmodell

Domänen überlegen Vereinheitlichung der Datentypen Z.B.: Spalte DESCRIPTION ist immer VARCHAR2(40)

Booleans NUMBER(1) mit Constraint auf 0 (FALSE) und 1 (TRUE) Normalerweise NOT NULL! Gleiche Namensgebung – z.B.: IS_MANAGER, HAS_CHILDS

Verarbeitungsflag NUMBER(1) mit Constraint auf NULL und 1 (TRUE) Index erstellen -> Enthält nur Datensätze mit 1

Historisierungsattribute Kann automatisch generiert werden

Seite 14


Datenmodell

Konsistentes Namensschema überlegen Tabellen Prefix (z.B.: NPT_T_) Spalten Prefix Foreign Key Benennung Constraint Benennung (IX_, UK_, PK_, FK_, CK_, ...) Spalten mit gleicher Bedeutung (DESCRIPTION, CODE, ...)

Tabellen und Spalten Kommentar verwenden

Immer mit Scripts ändern (Dev., Test, Produktion)

Seite 15


Datenmodell - Conclusio

Constraints, Constraints, Constraints!!!

Nicht auf Applikation verlassen

Letztes Bollwerk

Zeit investieren

Seite 16


Geschäftslogik

In die Applikation?

Direkt auf Tabellen inserten/updaten/löschen?

Was ist mit Überprüfungen?

Seite 17


Geschäftslogik - Objektkapselung

Package für jede Tabelle oder logische Tabelle/Tabellengruppe

Prozeduren createObjektname updateObjektname deleteObjektname validateSpalte/...

Eine Zentrale Stelle wenn es um die Erstellung oder Änderung des Objekts geht

Andere Objekte Initialisieren Notification, ...

Kann Initial generiert werden

Hilft bei Datenmodell Änderungen – Eine Zentrale Stelle

Auch andere Programme können Code verwenden (Batchjobs, ...) -> eine Art von SOA ;-)

Seite 18


Geschäftslogik - Objektkapselung

Wie in APEX verwenden?

Eigene DML Prozess Verlust von „Lost Update Detection“/Optimistic Looking Viel Arbeit

View mit INSTEAD OF TRIGGER Für APEX wie Tabelle Keine Änderung am Standardverhalten Siehe statements.sql

Seite 19


Geschäftslogik - Conclusio

Geschäftslogik raus aus dem UI !!!

Seite 20


Konfigdaten

Wiedereinspielbahre Scripts!

STORE Prozeduren Siehe statements.sql

Seite 21


Parsing Schema

Verwenden Sie das Applikationsschema?

Seite 22


Parsing Schema

Gefahr bei SQL Injection

„Run User“ mit eingeschränkten Rechten verwenden Z.B.: Kein DROP TABLE Recht

Mit Data Dictionary Scripts automatisch granten und Synonyms erstellen

Nachteil Wizard sieht die Synonyme nicht Workspace braucht auch Applikationsschema Immer Applikationsschema auswählen Applikationsschema hardcodiert

Alternative „Run User“ Parsing Schema erst bei Deployment setzen

Seite 23


Workspace

Einen? Mehrere?

Abhängig von Berechtigungsstruktur (Entwickler, Power User , Abteilungen)

Tendiere zu Einem

Single Sign On zwischen Applikationen im Workspace Über gleiche „Cookie Attributes“ in Authentification

Scheme

Seite 24



Bei kleinen Applikationen nicht sinnvoll

Bei größeren überlegenswert

Vorteile Unabhängige Release Zyklen Besser handhabbar Übersichtlicher Leichtere Teamentwicklung

Mögliche Nachteile Weniger integriert Unterschiedliche Templates Uneinheitliche Navigationsleisten Übergreifende Navigation komplizierter Weniger Synergie (gleiche Seiten, Lovs, ...)

Seite 25



Zentrale Master Applikation Login Allgemeine Seiten (Benutzerverwaltung, ...) Navigationsleisten Lovs ...

Spezifische Applikationen Subscription verwenden

Seite 26


Seitennummerierung

Fortlaufend? APEX weiß es am besten?

Nur bei kleine Applikationen

APEX Seitennummern sind nicht wirklich limitiert!

Es gibt immer zusammengehörige Seiten Übersichtsbericht mit Suche Detail Formular Vielleicht noch weiteres Detail Formular

50 oder 100 Schritte pro zusammengehörige Seiten

1.000 oder 10.000 Schritte pro Seitengruppe

Seite 27


Seitengruppen

Wer kennt Sie? Verwendet Sie?

Gutes Mittel um Applikation zu Strukturieren Admin Bereich Öffentlicher Bereich Shop ...

Verschiedene Darstellungsmöglichkeiten

Hilft Page Flow Diagram von ApexLib

Zuordnen über Seiteneigentschaften

Seite 28


APEX Einstellungen

Application Builder Defaults

Developer Preferences

UI Interface Defaults Defaults beim erstellen von Tabellen/Views Titel, Labels, Templates, Format Masken Applikationsübergreifend

Seite 29


APEX Einstellungen

Default Templates für Komponenten und Regionen

Shared Components\Themes\Edit Theme

Ein wenig versteckt

Seite 30


Teamentwicklung – Codierrichtlinien

Jeder entwickelt anders

Emotionales Gebiet!

Einheitliche Namensgebung Filenamen Variablen Parameter Konstanten Felder

Einheitliche Formatierung Gross-/Kleinschreibung Klammern Einrückung Leerzeichen

PL/SQL Aufrufe mit Non-Positional Syntax/Parameter

Seite 31


Teamentwicklung – Codierrichtlinien

Einheitliche Vorgehensweise Gleiche Patterns (z.B.: Geschäftslogik, APEX Seiten, ...)

Einheitliches Layout Labels, Tabs, Breadcrums, ... Feldtypen vereinheitlichen (Datum, Geldbeträge, …)

Für Oracle APEX und PL/SQL und SQL

Schriftlich!!!

Reviews durchführen

Seite 32


Teamentwicklung – Versionsverwaltung

Ist ein MUSS!!!

Auch bei 1 Mann Entwicklung!

Schnell etwas überschrieben/gelöscht

Historien Vergleich

Tools CVS + TortoiseCVS SVN + TortoiseSVN

Seite 33


Teamentwicklung – Versionsverwaltung

Alle Projekt relevanten Dateien Create Table Scripts Konfigdaten Packages Dokumente ...

APEX Applikations Export Manueller Export am Abend (APEX Builder oder SQL

Developer) Automatisiert mit apex\utilities\oracle\apex\

APEXExport.class und APEXSplitter.class Details siehe

http://jes.blogs.shellprompt.net/2006/12/12/backing-up-your-applications/

Seite 34


Teamentwicklung – Ticketsystem

Nachvollziehbar

Strukturiert

Viele Tools JIRA Bugzilla ...

Seite 35


Teamentwicklung – Gleichzeitige Entwicklung

Versionsverwaltung hilft dabei Locks Merge Nicht für APEX Export geeignet

APEX Page Locks verwenden Nicht alles geschützt (Shared Components) In 3.1 ein paar Bugs korrigiert Themengebiete für Entwickler festlegen Eine Zentrale Entwicklungsinstanz

Seite 36


Teamentwicklung – Gleichzeitige Entwicklung

Wenn was schief geht...

Seiten Export mit „As of xx min“ verwenden

Komplett Import beeinträchtigt andere Entwickler

DBA soll höheres Zeitfenster einstellen!!!

Seite 37


Teamentwicklung – Conclusio

Codierrichtlinien

Versionsverwaltung

Ticketsystem

Regelmäßige Exports

Page Locks verwenden

Einzel Seiten Export mit „As of“

Documents

Oracle APEX: Fortgeschrittene Techniken aus der Praxis => Design Patrick Wolf – Denes Kubicek - Dietmar Aust 17.03.2008 – 19.03.2008