Refactorización de la aplicación

La primera parte de la optimización, será retirar todos los mensajes, y, moverlos al módulo Constantes; ya hemos puesto algunos, ahora lo completaremos. De paso, revisaremos la programación, para hacerla mas homogénea. Al final de cada etapa, utilizaremos test, para comprobar que todo sigue funcionando

Los entity’s

Lo primero que haremos, es modificar la interfaz de Modelo, para añadir el acceso a los IDs, lo que nos obliga a hacerlo generico, y quedará asi

Modelo.java

public interface Modelo<T> {
	
	@Transient
	@JsonIgnore
	public T getId();
	@Transient
	@JsonIgnore
	public void setId(T t);
	
	@Transient
	@JsonIgnore
	public boolean isValidInsert();
	@Transient
	@JsonIgnore
	public boolean isValidUpdate();

}

Esto nos obliga a tocar todos los ENTITYS

En Cine.java

Y revisamos todos los Entitys para hacer esta modificación, que consiste en añadir el genérico a la implementación, y devolver/recibir el id en estos métodos

La clase abstracta y los servicios

Empezamos la aplicacion implementando en nuestro servicio IServicio, pero, posteriormente, creamos IServicioMas, que era una clase abstracta de la que podían heredar los servicios, y lo que hacemos ahora es mejorar nuestra clase abstracta, y luego haremos que todos nuestros servicios la hereden

Primero, establecemos que la clase genérica que recibimos en T, solo puede ser alguna que provenga de Modelo, con lo que garantizamos que tiene los métodos getId y setId

Ahora, ya disponemos de acceso al id, por lo que podemos añadir código como

A la vez que cambio los mensajes, para leerlos todos del mismo sitio

Y asi, podeis revisar este programa en Github, en esta version y vereis que el disponer del acceso a id, me permite mejorar mas esta clase, y dejar el servicio, en mi caso, con un solo método en algunos CRUDs

Y a la vez que borraba los demas, he pasado el mensaje a que se lea de Constantes

Otra cosa que podemos hacer es borrar IServicioNew y pasar todo el código a IServicio, luego veréis que solo teneis que modificar la clase abstracta

Cuando deis este paso, podemos mejorar un poco la Interface, definiendo ya alli la validacion, y la caracteristica de final, que luego replicaremos en IServicioMas

Aunque, vais a tener que revisar los servicios Cine y Entrada, para que hereden de IServicioMas y revisar qué métodos os podéis ahorrar, que serán la mayoría, excepto el mantenimiento…pero dependerá de las opciones de vuestro aplicativo, en cualquier caso, aprovechad para sacar todos los textos al módulo de Constantes

Hemos cambiado la salida de los métodos Insert y Update para que devuelvan el objeto que acaban de insertar o actualizar. Eso nos obligará a modificar servicio, controlador y test, pero hemos pensado que era mejor hacerlo asi, y la refactorización no nos debe dar miedo….

Ahora ya podeis pasar los test que habiais hecho para la capa de Servicios, y todos deberan funcionar, dejando aparte pequeños detalles con algun nombre de método, y los mensajes, que ahora se comparan desde Constantes

Los controladores

Nuestra siguiente tarea, sera revisar los controladores, empezando por CineController

Como hemos añadido la validación @CheckCineValidation() en todos los sitios donde hemos podido, no es necesario verificar si podemos leer el registro, cosa que haciamos antes, por lo que podemos simplificar el codigo, por ejemplo, el LeerUno, nos ha quedado asi (con nuevo fondo de STS….)

En cambio, en leerTodos, solo he retocado matices (el nombre del metodo que antes era leerAll y ahora es listarTodos o el mensaje

Y asi continuamos; podeis ver el trabajo terminado, en GitHub, a partir de la revisión 050- ….

Y continuamos con el resto de controladores. Al final, nos acordaremos de pasar los test, en donde puede que tengamos que corregir textos….

Si antes habiamos escritos los test, y los habiamos pasado, el trabajo que queda, puede que sea pesado, pero en absoluto preocupante. Solo debemos lanzar los test, y si queréis ejecutar todos, nos basta con

Cada error que marque el test, deberéis comprobar si es un error real, o solo es necesario modificar el test. Y aunque esta refactorización nos provoca un cierto trabajo, tambien nos asegura clases mucho más estables.

Tdas estas modificaciones, las tenéis hechas en GitHub en la version 050-….

Conclusión

Todo este desarrollo lo tendréis explicado con más detalle en youTube, y, aunque es conveniente que intentéis escribirlo TODO vosotros, si queréis renunciar a ello, lo teneis tambien en GitHub

Este desarrollo esta hecho para disponer de un fuente para explicar otros temas, tal y como se indica en Visión de conjunto con Spring

En YouTube