A lo largo del desarrollo de GNULab es seguro que cometí muchos errores y hay cosas que pueden ser claramente mejorables. Una de las sensaciones que tengo a veces es la redundancia entre algunos elementos que conforman la arquitectura de la aplicación. Sobretodo por la repetición de las clases que hacen referencia al modelo de la aplicación y eso posiblemente sea causa de algunos de los problemas de diseño que tiene la aplicación.
Una de las cosas que me fijé viendo los apuntes de Ingeniería del Software o viendo otro proyecto como Xesthotel, es la gran diferencia que existe en como está implementado el modelo. Xesthotel es una aplicación web y GNULab es una aplicación cliente-servidor y parte de la problemática la encuentro en como está implementado el servidor y en general como está luego implementado el cliente. La verdad es que me gustaría conocer la opinión de algunas otras personas al respecto.
Tal y como funciona xesthotel, en la lógica de negocio se puede ver que existen clases que implementan cada uno de los casos de uso de la aplicación de forma individual, implementando una interfaz que actúa como marcador, llamado NonTransactionalAction o TransactionalAction para distinguir entre operaciones transaccionales y operaciones no transaccionales. Cada una de estas operaciones usa el modelo para ser implementada, el modelo en Xesthotel simplemente es la implementación del nivel de acceso a datos, en el cual se implementa el patrón DAO para cada una de las entidades del modelo (NombreEntidadVO, InterfazDAO, FactoríaDAO, ImplementaciónConcreta[1..n]DAO), debido a la definición de como debe ser un objeto Value-Object, para representar relaciones complejas entre elementos dentro de la implementación de la acción se utiliza una serie de clases a las que se denomina ChunkVO.
Acciones (EDIT: El getAnalysis es no transaccional y el addAnalysis si es transaccional, se me fue la olla y los puse del revés en el diagrama. xD)
En GNULab esto es muy diferente, en realidad a las funcionalidades que representan los casos de uso se accede a través de una fachada que centraliza las operaciones de un grupo de casos de uso más o menos relacionados. Es decir que todos los casos de uso relacionados con la gestión de análisis están agrupados en una misma fachada lo que simplifica el acceso a estas funcionalidades. Cada una de estas implementaciones, delega en una operación del modelo (por ejemplo, añadir análisis delega en la operación crear análisis de Análisis), el cual la entidad del modelo es la responsable de implementar la creación de un análisis y conoce las relaciones que tiene con otros elementos del modelo, de esta manera crear análisis llamará a crear línea de cada una de las líneas de análisis.
Estas operaciones finalmente se encargan de llamar a un método interno de estas clases, que se encarga de convertir las clases en VO, después llaman a la factoría de su DAO correspondiente y por último realizan la llamada al crearAnálisis del DAO correspondiente.
Implementación en GNULab
El problema que veo a esto es la redundancia del modelo, que está replicado en lo que yo llamo capa del modelo y en la capa de acceso a datos. Mientras que en el modelo de acciones, las clases que representan el modelo de la aplicación no están repetidas, además de que existe la ventaja de poder modificar por separado cada uno de los casos de uso asegurándote no interferir en los demás casos de uso de la aplicación.
Además ahora viene el segundo problema de la arquitectura en general de GNULab. Hace tiempo aquí había puesto este diagrama, pero ahora le añado una pequeña crítica/observación que no había realizado en su momento.
Capas de GNULab
El problema es que en el cliente el Modelo vuelve a estar presente y la verdad que de una forma un poco inútil, ya que el modelo en el cliente simplemente se limita a delegar todas las operaciones en la interfaz RMI. Para hacer esto, la verdad que podría ahorrarme el modelo y que realmente el controlador trabaje contra la interfaz RMI, que es lo que realmente es el acceso a la implementación del Modelo.
