blog

Una decisión que hay que tomar a la hora de afrontar un proyecto en ADF es cómo y dónde vamos a desarrollar el código que soporte la lógica de negocio. Las dos posibilidades más obvias son:

1. basar todo el desarrollo en Java, a nivel de aplicación, o
2. implementar la lógica de negocio en PL/SQL en la base de datos, y usar java desde la aplicación para gestionar las capas de vista, controlador y modelo, dejando esta última capa como un mero acceso a BD.

Veamos las ventajas que aporta cada uno de los enfoques:

Ventajas desarrollo 100% ADF

• Todo el equipo de desarrollo tiene el mismo perfil. No debemos buscar especialistas en java y especialistas en PL/SQL (o especialistas en ambas cosas a la vez). De todos modos, alguien tendrá que saber SQL.
• Al tener un único origen de datos la gestión del control de versiones se simplifica.
• Por el mismo motivo, los despliegues no incluyen scripts de compilación de objetos de base de datos (procedimientos, funciones, paquetes o triggers), además del fichero que desplegaremos en Weblogic.

Ventajas desarrollo ADF + PL/SQL

• Los tiempos de desarrollo suelen ser menores, al ser PL/SQL un lenguaje de programación totalmente orientado al proceso de datos de BD.
• Los procesos intensivos de datos son más eficientes y proporcionan mejores tiempos de respuesta.
• Reutilización: al mantener la lógica de negocio junto a los datos, el impacto al cambiar el front-end es menor. Por ejemplo, si necesitamos llevar una parte de nuestra aplicación a una app móvil, no tendremos que volver a re-escribir código.
• Podemos mantener los datos coherentes en cualquier caso, independientemente de la aplicación (por ejemplo totales de facturas basados en la suma de sus líneas; relaciones en arco; etc).

Encontraremos una ventaja añadida al desarrollo ADF + PL/SQL si pensamos en el largo plazo. Nuestra experiencia nos muestra que la base de datos suele ser el último componente que se descarta en el ciclo de vida de una aplicación. En este caso disfrutaremos durante más tiempo de la inversión que hayamos hecho escribiendo la lógica de negocio en BD.

Sin embargo hay quien opina justo lo contrario, que no se debe ubicar nada en la BD y que esta debe ser un puro contenedor de datos, de modo que se pueda cambiar de un gestor de BD a otro, pero… ¿conoces a alguien que haya cambiado?. Por supuesto, cualquier decisión en un sentido u otro debe tomarse tras un análisis mucho más detallado y tomando en consideración más factores que los pueden citarse en una entrada de blog.