🇺🇸 Read in English
Introducción: Modularidad, el Secreto del Código Escalable
En el desarrollo con Oracle APEX, muchos proyectos comienzan rápido… y también se complican rápido.
A medida que las aplicaciones crecen, las páginas se multiplican, los procesos se duplican y los cambios se vuelven riesgosos.
Ya hemos hablado de Buenas Prácticas, Seguridad, UX y Rendimiento. Ahora toca hablar de arquitectura.
Aquí es donde entra en juego la modularidad: la capacidad de construir aplicaciones Oracle APEX organizadas en piezas reutilizables, independientes y mantenibles.
Una aplicación modular reduce errores, acelera el mantenimiento y facilita el trabajo en equipo.
Si trabajas en equipos o mantienes varias aplicaciones Oracle APEX, entender y aplicar modularidad puede cambiar por completo tu flujo de desarrollo.
En este APEX Insights, construiremos una arquitectura modular desde cero, explorando tres pilares clave:
- Paquetes PL/SQL para encapsular la lógica de negocio.
- REST Data Sources para compartir datos y servicios entre aplicaciones.
- Componentes compartidos de Oracle APEX para mantener coherencia visual y funcional.
Usaremos un ejemplo técnico: un módulo de autenticación y logs centralizado, reutilizable por varias aplicaciones Oracle APEX dentro del mismo workspace.
1. Conceptos Clave: Qué Significa Modularidad en Oracle APEX
Antes de escribir una sola línea de código, entendamos qué buscamos con un diseño modular:
- Separación de responsabilidades: cada módulo tiene una función clara (ej. autenticación, notificaciones, configuración).
- Reutilización: la lógica y los componentes pueden ser usados en más de una aplicación.
- Mantenibilidad: los cambios en un módulo no rompen los demás.
- Desacoplamiento: los módulos interactúan a través de interfaces (como paquetes o REST APIs), no directamente entre sí.
Estos principios son la base de toda arquitectura sostenible, sin importar el tamaño o complejidad del proyecto.
2. Estructura Recomendada del Proyecto Modular
Antes de escribir código, define una estructura clara.
Esta puede parecer un detalle menor, pero te ahorrará horas de mantenimiento más adelante.
Estructura inicial sugerida:
/apex-insights/
│
├── db/
│ ├── packages/
│ │ ├── auth_core.pks
│ │ ├── auth_core.pkb
│ │ ├── log_utils.pks
│ │ ├── log_utils.pkb
│ └── install/
│ ├── create_users.sql
│ ├── seed_data.sql
│
├── rest/
│ ├── auth_api/
│ │ ├── get_user_status.sql
│ │ ├── post_login_audit.sql
│ └── system_monitor/
│ ├── get_logs.sql
│
├── apex/
│ ├── shared_components/
│ │ ├── templates/
│ │ ├── lists/
│ │ ├── substitutions/
│ └── apps/
│ ├── core_app/
│ ├── admin_app/
│ └── user_portal/
└── docs/
└── architecture.md
Consejos clave:
- Usa un prefijo para tus paquetes (ej.
core_, mod_, app_).
- Mantén separados los scripts de instalación e inicialización.
- Documenta las dependencias entre módulos (idealmente en
architecture.md).
3. Módulo 1: Paquetes PL/SQL — El Corazón del Backend
Los paquetes PL/SQL son la base de toda arquitectura modular en Oracle.
Permiten centralizar la lógica de negocio y exponer funciones limpias y reutilizables.
Los paquetes no solo agrupan procedimientos: protegen tu lógica de negocio y evitan duplicaciones en diferentes aplicaciones.
Ejemplo: Paquete de Autenticación
auth_core.pks
CREATE OR REPLACE PACKAGE auth_core AS
FUNCTION validate_user(p_username VARCHAR2, p_password VARCHAR2) RETURN BOOLEAN;
PROCEDURE register_login(p_username VARCHAR2);
END auth_core;
/
auth_core.pkb
CREATE OR REPLACE PACKAGE BODY auth_core AS
FUNCTION validate_user(p_username VARCHAR2, p_password VARCHAR2) RETURN BOOLEAN IS
v_count NUMBER;
BEGIN
SELECT COUNT(*) INTO v_count
FROM users
WHERE username = p_username
AND user_password = STANDARD_HASH(p_password, 'SHA256');
RETURN v_count = 1;
END validate_user;
PROCEDURE register_login(p_username VARCHAR2) IS
BEGIN
INSERT INTO login_audit (username, login_time)
VALUES (p_username, SYSDATE);
END register_login;
END auth_core;
/
💡 Consejo: coloca los paquetes de negocio en un schema centralizado (CORE_DB o APEX_UTILS) y accede a ellos desde cualquier app Oracle APEX con privilegios limitados (GRANT EXECUTE ON auth_core TO app_user;).
4. Módulo 2: REST Data Sources — Conectando Aplicaciones
Cuando varias aplicaciones necesitan los mismos datos o servicios, lo peor que puedes hacer es copiar la lógica.
Con REST Data Sources, puedes centralizar esa información sin reinventar la rueda.
Ejemplo: Servicio de Logs (RESTful)
-- SQL Handler: GET_LOGS
SELECT username, action, log_date
FROM app_logs
WHERE log_date > SYSDATE - NVL(:DAYS, 7)
ORDER BY log_date DESC;
Configuración recomendada:
- Endpoint:
/ords/core/logs/
- Métodos:
GET, POST
- Autenticación: OAuth2 o APEX Session Cookie
- Caché: habilita
Cache-Control para consultas estáticas.
💡 Consejo: usa APEX_WEB_SERVICE.MAKE_REST_REQUEST para consumir servicios entre apps del mismo workspace y mantener un flujo controlado.
5. Módulo 3: Componentes Compartidos — Reutilización Visual y Lógica
Así como el backend tiene sus módulos, la interfaz también puede volverse modular.
Los componentes compartidos (Shared Components) son tu mejor aliado para mantener coherencia visual entre aplicaciones.
Ejemplos comunes:
- Templates personalizados: botones, regiones, listas y reportes.
- Listas de valores (LOVs) y sustituciones: definidas una vez, usadas en múltiples apps.
- Bundles de JavaScript o CSS: centralizados en una app base y referenciados por las demás.
Ejemplo: Banner de Sesión Unificado
En tu app base (por ejemplo, “Core App”), crea una región HTML:
<div class="session-banner">
Logged in as: &APP_USER.
</div>
Luego, usa “Copy Shared Components” en otras apps para importar el banner y mantener coherencia visual sin reescribir nada.
6. Ejemplo Integrado: Módulo de Autenticación y Logs
Supongamos que tienes tres aplicaciones: Portal de Usuarios, Admin Dashboard y Core App.
- Core App: contiene
auth_core y log_utils (backend).
- Admin Dashboard: consume REST
/ords/core/logs/ para mostrar auditoría.
- Portal de Usuarios: usa
auth_core.validate_user para login.
- Ambas apps: importan el banner compartido de sesión.
El resultado es un entorno modular, conectado y fácil de mantener, donde cada pieza cumple un propósito y puede evolucionar sin romper las demás.
7. Beneficios de una Arquitectura Modular
- Escalabilidad: agrega nuevos módulos sin romper los existentes.
- Colaboración: distintos equipos pueden trabajar en módulos separados.
- Seguridad: permisos más claros y controlados entre esquemas.
- Reutilización: evita duplicar lógica y componentes.
- Depuración más sencilla: si algo falla, sabes exactamente en qué módulo está.
Conclusión: Construye Módulos, No Monolitos
La modularidad no es un lujo, es una estrategia.
En Oracle APEX, dividir tu aplicación en paquetes, servicios REST y componentes compartidos transforma la forma en que construyes y mantienes tus proyectos.
Empieza por un módulo pequeño — como autenticación o logs — y verás cómo tu entorno Oracle APEX evoluciona hacia algo más escalable, limpio y profesional.
Referencias y Recursos Útiles
- Oracle APEX REST Data Sources Guide
- Oracle Database PL/SQL Packages and Types Reference
- Joel Kallman’s Blog – Reusability in APEX Components
🚀 ¿Necesitas un Experto en APEX?
Ayudo a empresas a construir arquitecturas escalables y modulares. Si tu aplicación es un monolito difícil de mantener y necesitas una refactorización profesional, hablemos.
☕ Agendar una Llamada | 💼 Conectar en LinkedIn
