Creación del proyecto
El video de TV.UM.ES está pendiente de modificar. Hay que seguir las indicaciones a partir de aquí.
Para crear un proyecto de Spring Boot en Eclipse:
Nos vamos a File → New → Other y seleccionamos Spring Boot → Spring Starter Project.
En la ventana de creación de proyecto, escribimos en "Service URL" la siguiente dirección "https://apidesa.um.es/mncs/api-base/public/"
Es necesario estar en la red de Ática físicamente o a través de VPN para acceder a la URL.
- Configurar el nombre de proyecto en Name. Se recomienda utilizar el mismo nombre de proyecto que aparezcla en la URL de gitlab.
Por ejemplo: URL => https://gitlab.com/umugit/atica/desarrollo/mncs/daaspoc-api
Name => "daaspoc-api" - Group, Artifact y Version se rellenan automáticamente.
- Completar Description con una breve descripción del propósito general del API.
- Package: establecer el paquete raíz de la aplicación. "aplicacion" no debe coincidir con Name. En el ejemplo anterior, aplicacion=daaspoc.
SpringBoot por defecto escanea los componentes que están bajo el paquete raíz, que es donde se encuentra la clase inicial. Es imprescindible que todo nuestro código esté agrupado en paquetes bajo el raíz. Si tenemos es.um.atica como raíz los nuevos paquetes deberán estar bajo es.um.atica.*.
El comportamiento, si tenemos esto mal, es que no tendrá en cuenta las anotaciones de Spring por lo que no se crearán componentes, no funcionarán las inyecciones, no se levantarán servicios (dará un not found), etc. Estos errores se darán en tiempo de ejecución, no durante el desarrollo.
- En la siguiente pantalla se escogerán las dependencias a incluir en el proyecto:
- La versión de Spring-Boot vendrá fijada con la versión actual del parent de aplicaciones FundeWebJS (fundewebjs-api-parent). No se puede modificar.
- Seleccionar obligatoriamente la dependencia "Fundewebjs-starter". Esta librería gestiona todas las dependencias y funcionalidades comunes.
- Si se quiere seleccionar alguna librería y no se encuentra en el listado, no hay que preocuparse, vendrá incorporada automáticamente en Fundewebjs-starter.
- Presionar Finish para generar el proyecto e importarlo automáticamente a eclipse.
- Una vez importado el proyecto, si aparece una ventana de error de eclipse al hacer build, pinchar con el botón derecho en el proyecto => Properties => Builders => Deshabilitar CDI (Contexts and Dependency Injection) Builder y aplicar.
Con esto tendremos el proyecto creado, con la clase NombreproyectoApplication.java (nombre de proyecto correspondiente), que será la que inicie la ejecución de la aplicación. Una vez tengamos el proyecto creado, podemos pasar a añadir la configuración necesaria.
Estructura de los proyectos Spring Boot
La estructuración de la capa backend será similar a la indicada para las aplicaciones Fundeweb basadas en JSF ya que la filosofía sobre cómo gestionar la lógica de negocio y obtención de datos es la misma. No obstante nuestros backends estarán basados en SpringBoot y no tendrán incorporada la capa Frontend por lo que hay que ajustar las peculiaridades del cambio de tecnología.
El esquema general será el siguiente:
Basándonos en el esquema anterior nuestra aplicación debe constar de tres capas:
Controladores Rest
Será la clase o clases que expongan la API Rest por lo que establecerán el punto de interconexión entre backend y frontend. Está desacoplada del fontend por lo que las APIs expuestas podrán ser consultada desde cualquier aplicación o navegador lo que hace primordial asegurar la autenticación y autorización de los puntos de interacción de las partes privadas. También debe asegurar que la parte pública no permite acceder a información diferente de la propuesta o a partes privadas.
Tras la autorización y autenticación (si procede) deberá validar los datos y parámetros que llegan junto con la petición rest y actuar según proceda. En caso de ser todo correcto deberá redirigir a la capa de negocio o servicios (services) donde se lanzará la lógica de negocio de nuestra aplicación para atender a dicha petición rest.
Una vez procesado los datos deberá devolver objetos de tipo DTO ya que no debemos exponer entidades completas, en caso de ser necesario realizará la transformación de entidades a DTO.
Las características generales son:
- Todas los controladores que expongan APIs rest deberán estar dentro del paquete de servicios rest (paquetes con sufijo rest): "es.um.atica.xxx.xxx.rest".
- Proveer los endpoints para que los diferentes servicios accedan a nuestro backend.
- Dividir los endpoints entre públicos y privados: Para ello los endpoints públicos deberán ir en el path ".../public/..." y los privados en ".../private/..."
- Controlar el acceso a los diferentes endpoints privados tanto a nivel de autenticación como de autorización.
- Estará anotada con @RestController
- Deberá indicar el path donde este controlador escucha: @RequestMapping(value = "/public/....")
- Varios manejadores podrán mapear la ruta raiz indicada en @RequestMapping, pero lo recomendable es que cada manejador gestione un contexto /public/alumnos, /public/pdi, etc.
- En las respuestas a las peticiones deberá usar los códigos HTTP para indicar el estado devolviendo 200 sólo si la respuesta es correcta, en caso de errores controlados se deberá hacer uso de los códigos 400
- Deberán tratar las excepciones producidas para dar una respuesta coherente a la parte cliente.
Servicios
Será la clase o clases que gestionan la lógica de negocio gestionarán la obtención de datos bien desde base de datos haciendo uso de los @Repository pertinentes o de clientes Rest / SOAP, coordinarán el flujo de ejecución del código y deberán controlar posibles problemas y situaciones inesperadas para dar una respuesta controlada al cliente que ha invocado a este servicio.
Tendrán dependencias con los elementos que actúen en un determinado proceso de negocio y serán los únicos "beans" que inyecten los controladores (@RestController). Un servicio podrá inyectar cualquier elemento que requiera para su lógica, salvo los controladores ya que en este caso podríamos introducir dependencias circulares y crearemos un acoplamiento innecesario en nuestra aplicación.
Las clases que contienen servicios deben incluirse en un paquete con el sufijo servicios: "es.um.atica.xxx.xxx.services" y deben tener tanto su implementación Java como su intefaz siguiendo la siguiente nomenclatura:
- Interfaz: MiInterfaz
- Implementación: MiInterfazImpl
Repository, PAO, Entity, DTO, MODEL
Esta capa será la encargada de dar acceso a los datos de la aplicación almacenados en base de datos o modelar los objetos del sistema que no tienen correspondencia directa con el modelo de base de datos.
El acceso a base de datos se llevará a cabo principalmente por las clases anotadas con @Repository que provee SpringBoot: @CrudRepository , @JpaRepository, @Repository, esto lo podemos consultar en JPA: Acceso a base de datos
Dependiendo del tipo de objeto estará en un paquete diferente.
- Repository: Serán los repositorios que accederán a la base de datos se deberán alojar en "es.um.atica.xxx.xxx.repository"
- PAO/DAO: Serán los encargados de llamar a paquetes/prodecimientos de base de datos, deberán estar en "es.um.atica.xxx.xxx.pao/dao"
Entity: Clases Java que mapean en entidades "es.um.atica.xxx.xxx.entity"
DTO/MODEL: DTO Clases java que mapean entidades a tipos más simples de cara a devolver en los servicios REST "es.um.atica.xxx.xxx.dto". MODEL Clases Java que se usan en la aplicación como modelo de datos pero que no equivalen a entidades "es.um.atica.xxx.xxx.model"