Entwickeln mit APEX: Tipps

Die wichtigste Empfehlung für APEX-Entwickler ist: Wenn es für eine Anforderung eine Standardkomponente gibt, sollte man diese nach Möglichkeit nutzen und nicht etwas Eigenes programmieren. Das wird besonders bei den Berichten deutlich: Man benötigt nur eine SQL-Abfrage und ein Template. Programmiert man den Bericht mitsamt der tabellarischen Darstellung dagegen selbst, ist das wesentlich aufwendiger.

Doch was ist, wenn sich der Bericht komplizierter gestaltet? Anforderungen wie gleitende Durchschnitte und laufende Summen sind mit SQL-Funktionen (analytischen Funktionen) zu lösen. Sobald die Anforderung in eine SQL-Abfrage übersetzt ist, lässt sich an der Oberfläche ein Standardbericht verwenden.

Die Datenbank ist mit einer umfangreichen Funktionsbibliothek ausgestattet; der größte Teil davon ist in der Standard-Edition verwendbar. Beispiele dafür sind:

• Volltextrecherche mit Oracle TEXT
• Geodatenverwaltung mit Oracle Locator
• einfache Bildverarbeitung mit Oracle MultiMedia

Indiziert man einen Dokumentenbestand mit TEXT, so erfolgt die Recherche mit SQL-Abfragen und der Funktion CONTAINS. Man kann nun einen APEX-Bericht erzeugen und die Volltextabfrage damit durchführen; an der Oberfläche lässt sich mit den Standardkomponenten Zeit sparen.

Die Verwendung der Standardkomponenten ist der Schlüssel zur Wartbarkeit größerer Applikationen. Wenn ein Entwickler auf eine bestehende Anwendung schaut, kann er sich unter den Begriffen Report oder Authentifizerungsschema sofort etwas vorstellen; der Blick in den Code ist erst nötig, wenn Details gefragt sind. Einzelne Komponenten lassen sich gezielt exportieren und damit in andere Anwendungen übertragen. Daher gibt es in der Praxis durchaus "APEX-Basisapplikationen", also leere Anwendungshüllen mit für das Unternehmen nötigen Komponenten (Authentifierungsschemas, Layout-Templates etc.). Diese Komponenten sind für neue Applikationen zu verwenden. Auch das erläuterte APEX Data Dictionary lässt sich gezielt für Wartungs- oder Qualitätssicherungsarbeiten nutzen. Ein Beispiel hierfür sind Patrick Wolfs APEX Essentials; ein freies Werkzeug zur Qualitätsicherung von APEX-Anwendungen.

Fazit und Ausblick

APEX eignet sich als Entwicklungstechnik je mehr, desto mehr die Anwendung mit Tabellen in der Datenbank arbeitet, desto mehr Datenbankfunktionen sie nutzt und desto mehr APEX-Standardkomponenten zu verwenden sind. Typische Beispiele sind Anwendungen zur Pflege und zum Betrachten von Datenbeständen oder einfaches Reporting. In diesen Fällen kann APEX seine enge Bindung an die Datenbank ausspielen. Der Entwickler muss sich in keiner Weise mehr um ORM beziehungsweise um eine Datenbankzugriffsschicht kümmern.

Anwendungen, die nur wenig oder überhaupt keinen Bezug zur Datenbank haben, sind für APEX ungeeignet. So ist es zwar technisch möglich, aus einer APEX-Anwendung heraus mit Webservices und komplett ohne Datenbankobjekte zu arbeiten, aber das wäre nicht sinnvoll. Man könnte nur wenige APEX-Komponenten nutzen. Hier werkelt man mit Java-, PHP- oder .NET-Techniken sicherlich effizienter.

Seit einiger Zeit stellt Oracle einen öffentlichen Demoserver für APEX bereit. Auf apex.oracle.com kann man sich kostenlos einen Workspace einrichten und sofort mit dem Testen beginnen. Die Website der deutschen APEX-Community enthält Tipps, Tricks und "How-to"-Dokumente zum Entwickeln mit APEX und der Oracle-Datenbank.

Neu ist das Werkzeug zur Migration von Oracle-Forms-Anwendungen nach APEX. Darüber hinaus haben die Entwickler kleinere Details im Bereich Sicherheit eingeführt: So lassen sich Formularelemente nun verschlüsselt im Session State speichern. Wie es mit APEX 4.0 weitergeht, kann man im "Statement Of Direction" nachlesen. Demnach ist Ajax ein großes Thema. Geplant ist die Option, eigene Typen für Formularelemente zu definieren und diese in die Entwicklungsumgebung einzubinden. Die APEX Websheets (der Name steht noch nicht endgültig fest) sollen es dem Endanwender erlauben, Arbeitsblätter einer Tabellenkalkulation direkt nach APEX hochzuladen, zu bearbeiten, zu speichern und anderen den Zugriff darauf zu ermöglichen. Das ist zwar heute schon möglich, allerdings muss man dafür eine Tabelle und eine APEX-Anwendung (mit Formularen und Berichten) erstellen. In Version 4.0 kann der Anwender das, ohne Tabellen oder Anwendungen erstellen zu müssen.

Carsten Czarski
ist als Leitender Systemberater bei der Oracle Deutschland GmbH, Business Unit Database, beschäftigt.