Tags: Apex | Database | Oracle

Val niet in de, yafet du-jour, Apex valkuil

Val niet in de, yafet du-jour, Apex valkuil Oracle Application Express (Apex) blijft onverminderd populair. Ik zie nu zelfs organisaties die na maanden met JDeveloper gestoeid te hebben, daar een punt achter durven zetten, en integraal switchen naar Apex. Omdat je daar “zo lekker snel webpages mee kan bouwen” op je Oracle database.

Ja dat is waar. Maar pas op: val niet in de yafet valkuil.

Wat is die valkuil? In eind tachtiger jaren jargon: lekker dikke forms bouwen. Ofwel, allerlei data en business logic ‘wegclicken’ in de UI technology du-jour. Terwijl dat nou juist de technology is waarvoor je immuniteitsgehalte het hoogst zou moeten zijn. Je moet in staat zijn om eenvoudig van UI-technology te kunnen switchen. Dat is namelijk het deel van de technology stack waar de (continue) dynamiek zit. Een UI-technology independent approach—aka. de dikke database approach—stelt je hiertoe in staat.

In een eerdere column heb ik het al eens gehad over een layered approach voor de dikke database. De business services layer daarvan moet u behoeden voor de yafet valkuil. De business services layer is bedoeld om precies die services te publiceren die door de UI pages aangeroepen worden. Zij vormen het contract wat een page met de database heeft. Ook als de UI-technology toevallig DBMS-hosted is, moet u die laag blijven toepassen en dus alle business en data logic uit de Apex layer houden.

Wees voorbereid op enkele major upgrade trajecten voortkomend uit nieuwe Apex releases die nog moeten komen. Enkele observaties die mij bij Apex opvallen.
  1. Sorely missing: een degelijke “concepts guide”. Alle Oracle documentatie rondom Apex is wat mij betreft te veel point-and-click achtig (à-la Microsoft tools documentatie). Als je serieus met Apex aan de slag wil, dan is een eerste vereiste een grondig begrip van hoe dit “html genererend” pl/sql framework nou echt werkt.
  2. Een duidelijk transactie-model (welke gedocumenteerd zou moeten zijn in een concepts guide). Met Apex bouw je Window-on-Data (WoD) applicaties. Elk request (http get/post) zal een transactie in Oracle worden. Wanneer begint deze transactie? Vinden er interne commits plaats? Kunnen we naar savepoints terug gaan? Moeten we zelf committen, of is er een auto-commit mechanisme? Allemaal vragen die van belang zijn, en waar je momenteel met trial-and-error pogingen zelf achter moet zien te komen.
  3. Support voor ref-cursoren. Deze heeft te maken met heldere kunnen scheiden van producer (de dikke database) en consumer (Apex page rendering) van query resultaten. Momenteel kun je een Apex report niet baseren op een ref-cursor .
  4. Server error handling. Er is duidelijk nog niet genoeg nagedacht over het netjes kunnen handlen van (database)server-errors. Elke unhandled exception die tijdens een request optreedt doet je applicatie default naar een empty page navigeren met daarop de pl/sql error-stack .
  5. Client-side validation processing niet declaratief aanwezig. Elke WoD applicatie wil graag een aantal zaken aan de client-kant valideren, zonder ervoor helemaal naar de server te hoeven gaan. Attribute and tuple constraints zijn de typische voorbeelden van validaties die je middels Javascript wil kunnen uitvoeren alvorens een server request geinitieerd wordt. Again: missing functionality.
Deze observaties geven mij het gevoel dat Apex qua volwassenheid vergelijkbaar is met SQL*Forms 2.0 uit 1987. Desalniettemin blijf ik onverminderd enthousiast over Apex. Wat Oracle*Forms de afgelopen 20 jaar is geweest, ligt volgens mij de komende 20 jaar in het verschiet voor Apex. Ook met SQL*Forms 2.0 zijn 20 jaar geleden grote business critical systemen gebouwd. Velen daarvan zijn continu mee-gemigreerd en draaien nu nog met een current Oracle*Forms release. En het meerdere keren mee-migreren gaat juist het gemakkelijkst als je de UI-technology ‘thin’ ingezet hebt.

Oh ja, waar die afkorting voor staat?

Yet Another Front End Technology. Nogmaals, val niet in haar valkuil.

RuleGen
Ir. Toon Koppelaars

¹ Er is wel een workaround: bouw een pipelined table function wrapper over de ref-cursor en baseer je report op de function.

² Gelukkig zijn er wel initiatieven die dit netjes voor ons kunnen regelen. Zoals bijvoorbeeld het Apexlib framework van Patrick Wolf.

Lees meer over RuleGen
Ga terug naar We Love IT uitgave 5 - 2008
Advertentie