Una distinzione utile
In molti progetti APEX la tentazione è mettere regole di business nella pagina: processi, dinamiche, JavaScript. Funziona in demo. In produzione, dopo il secondo rilascio e il terzo sviluppatore, diventa difficile da spiegare.
Preferiamo un confine chiaro: la pagina orchestra l’esperienza; lo schema e il PL/SQL decidono cosa è accettabile.
Cosa resta in APEX
APEX è eccellente per:
- layout, navigazione e accessibilità dell’interfaccia
- binding di report e form alle sorgenti dati
- autorizzazioni a livello di pagina e di componente
- feedback immediato all’utente
Qui il mestiere è ridurre attrito: meno click, messaggi precisi, flussi leggibili.
Cosa preferiamo nel database
Validazioni strutturali, vincoli, package di dominio e procedure che rappresentano un’operazione di business appartengono allo schema. Motivi pratici:
- Una sola fonte di verità — la stessa regola vale da APEX, da un job, da un’API ORDS.
- Testabilità — un package si prova senza ridisegnare la UI.
- Evoluzione controllata — si cambia la regola senza riscrivere cinque pagine.
Non è dogmatismo: è mantenere il perimetro stabile quando l’interfaccia cambia.
Un criterio operativo
Prima di aggiungere un processo di pagina, ci chiediamo: questa regola deve valere anche se l’utente non passa da questa schermata? Se sì, la collocazione naturale è il database.
APEX resta lo strumento con cui le persone lavorano. Oracle Database resta il posto in cui il sistema decide.
Approfondire
Nel Journal e nelle risorse aperte condividiamo strumenti e note di campo. Per un confronto sul tuo schema o su una migrazione Forms → APEX, scrivici.