A la hora de implementar nuestros proyectos FundeWeb debemos evaluar la envergadura de los mismos para tener claro cómo debemos estructurarlos distinguiendo entre dos tipos de proyectos:
Proyectos pequeños cuya funcionalidad no es necesaria dividirla en módulos.
Proyectos medianos/grandes cuya funcionalidad se divide en varios módulos.
Estos proyectos al ser de tamaño pequeño basta con hacer uso de la estructura que proporciona el arquetipo:
A continuación explicamos qué debe contener cada uno de los paquetes de la arquitectura anterior:
backbeans: En este paquete debe contenerse todos los beans de respaldo que gestionen las pantallas de nuestra aplicación.
das: Deberá contener todos las clases de acceso a a objetos de base de datos. Contiene tanto la interfaz (.interfaces) como las implementaciones (.impl).
dto: Contiene los objetos que representan datos del sistema pero que no son entidades.
entities: Contiene los objetos del sistema que son entidades (se mapean directamente con tablas de la bbdd).
exceptions: Contiene las excepciones que hayamos creado nosotros para nuestra aplicación.
paos: Contiene las clases java encargadas de hacer las llamadas a los paquetes y funciones de base de datos. Engloba tanto interfaces (.interfaces) como implementación (.impl).
security: Contiene todas las clases, tanto del modelo como de control, para gestionar la autenticación y autorización en la aplicación.
services: Contiene todas las clases que gestionan la capa de servicios de la aplicación. Esta capa es la que da servicio a los diferentes componentes de la aplicación, NO se refiere a servicios web. Contiene tanto la interfaz (.interfaces) como la implementación (.impl).
services.rest:Contiene todas las clases que gestionan la capa de servicios REST de la aplicación.
services.soap:Contiene todas las clases que gestionan la capa de servicios SOAP de la aplicación.
El esquema de este tipo de proyectos es el siguiente:
Estos proyectos son de tamaño medio/grande y se caracterizan porque son divisibles en módulos de funcionalidad. Cada módulo puede tener sus propios controladores, servicios, pao, etc.
En este tipo de proyectos es crítico tener bien identificados y delimitados los diferentes módulos que los componen y las dependencias entre ellos. Un módulo puede utilizar los servicios otro, pero no debería poder tener un acceso mayor. La interacción entre módulos debe hacerse a través de la capa de servicios de cada uno para minimizar el solapamiento.
Un ejemplo de estructura modular sería el siguiente:
Esta estructura incluye un sólo módulo asumiendo que la aplicación accederá también a intalio, por lo que se han incorporado los paquetes correspondientes. A continuación explicamos de manera más detallada esta estructura.
Estos paquetes nos definen la estructura, en nuestro código fuente, que debe presentar nuestra aplicación para organizar los diferentes formularios bpm y la interacción con nuestra aplicación.
Los paquetes destinados a gestionar código o entidades relacionadas con un proceso BPM deben comenzar por es.um.atica.miproyecto.bpm.
Dentro de esta jerarquía distinguieremos los siguientes paquetes:
comun.control y comun.xml: Contendrán las clases Java que sean comunes a todos los formularios, como por ejemplo clases abstractas de control, ficheros Java-JAXB comunes a toda la arquitectura, etc.
procesoX.formularioX.control y procesoX.formularioX.xml: Contendrán las clases Java concretas de un formulario concreto. “procesoX” representará el código del proceso, “formularioX” representa el código de formluario, se recomienda que este código se al mismo que el nombre del fichero xhtml de ese formulario. Por ejemplo: P01F01 (formulario 01 del proceso 01) para facilitar la localización de los recursos.
La estructura de paquetes de cada módulo es la misma que en los proyectos de un sólo módulo, indicando en la ruta el nombre del módulo al que pertenece el paquete.
Los ficheros referente a la vista (xhtml) están incluidos en una ruta diferente al código fuente Java. Esta ruta es: src/main/webapp. En esta ruta estarán todos los recursos que son públicos y accesibles por cualquiera. Dentro de esta carpeta existe otra carpeta llamada paginas en la que pondremos todos los ficheros xhtml que requieran de autenticación. Así pues:
En src/main/webapp: pondremos todas las páginas y recursos públicos.
En src/main/webapp/paginas: pondremos todas las páginas privadas que requieran autenticación.
En caso de una aplicación pequeña, sin módulos, basta con esta estructura, creando dentro de páginas una carpeta “admin” para todas las pantallas relacionadas con funcionalidad de administrador.
En caso de una aplicación media/grande, dentro del directorio paginas deberemos crear una o varias carpetas según módulos de funcionalidad. Es decir, todas las pantallas relacionadas con un módulo de la aplicación o flujo de ejecución deberán estar dentro de la misma carpeta.
Por otro lado, si estamos haciendo uso de procesos BPM se deberá crear una carpeta con el código del proceso y dentro todas los ficheros xhtml que tengan que ver con el flujo de dicho proceso. El nombre de estos ficheros xhtml debe estar compuesto por el código del proceso y el código del formulario.
Un ejemplo de ruta completa de un formulario de un proceso BPM sería: https://miaplicacion.um.es/miaplicacion/paginas/pc01/pc01f01.xthml
Siendo pc01 el código del proceso y f01pc01.xhtml el nombre del formulario.