martes, 27 de enero de 2015

Un proyecto en NetBeans de principio a fin (VIII). Integración transaccional de la lógica de negocio

¡Ey! Ya creíais que había terminado hasta el gorro de este tutorial y que no volveríais a ver un tostón de este calibre ¿Eh?. Lo cierto es que el trabajo y otros avatares (como que se me fue al garete el proyecto de NetBeans con el que estaba llevando este tutorial paso a paso...) han hecho que pase tanto tiempo desde la última entrada (creo que exactamente un año) que a punto he estado de darlo por perdido, olvidado, defenestrado y enterrado... Sin embargo aquí estamos de nuevo, al menos durante un capítulo más... ¡Qué no desfallezca el ánimo! (no hay otra forma de afrontar esto)...

En fin que me enredo, el objetivo de esta unidad es explicar las bondades del mapeo objeto-relacional, u ORM por sus siglas en inglés (Object-Relational Mapping), proporcionado por las tecnologías EJB y JPA para recolectar datos de una petición web y escribirlos en una base de datos en el back-end. Básicamente, ORM es una técnica de programación que permite convertir los datos entre el sistema de tipos usado por un lenguaje de POO y una base de datos relacional, utilizando un motor de persistencia.

El modelo de dominio es EL MODELO.

Diseñar primero el esquema de datos en persistencia es un fallo tremendo y, por lo visto, muy común.

El Dominio es la razón por la que la aplicación existe y todo debe gravitar alrededor de el. El dominio no debe depender de nada, y mucho menos de detalles de implementan de persistencia.

El esquema de persistencia debe de estar al servicio del modelo de dominio y no al revés. Una vez que se tienen diseñadas las entidades, sus relaciones y los servicios de dominio es cuando se debe crear un esquema de datos que permita persistir en el tiempo esa información.

Si diseñamos el esquema de persistencia primero; nuestros servicios y entidades se van a ver llenas de hacks y workarrounds de lo más bizarros, que permitan casar los casos de uso del dominio con la persistencia; puesto que ésta no ha sido diseñada para el dominio, si no que ha sido diseñada simplemente para evitar redundancias e inconsistencia de datos sin tener en cuenta las necesidades de las operaciones y reglas del dominio; ya que estas todavía no han sido analizadas, modeladas ni probadas.

Esta es la razón por la que Eric Evans recomienda empezar el desarrollo diseñando el dominio e ignorar completamente cualquier cosa relativo a la persistencia.

Es la persistencia la que se debe adaptar al dominio. Es por esto, por lo que existen incluso técnicas para adaptar un diseño orientado a objetos a persistencia relacional:


Tabla por jerarquía: Desnormaliza el esquema y utiliza una columna discriminadora.

Tabla por tipo: Representa herencia utilizando relaciones.
Tabla por clase concreta: La persistencia relacional no es consciente de ninguna herencia puesto que no se representa de ninguna manera.



Regla de Oro: Cuando desarrollas una aplicación la persistencia NO EXISTE. 


Primero diseña una aplicación que cumpla el dominio; en la que tus entidades estén simplemente en arrays en memoria y que cada vez que arranques la aplicación la información desaparezca. Una vez tienes esto completado es la hora de crear un esquema de persistencia que permita almacenar las entidades y sustituir los repositorios que almacenan y buscan en los arrays por repositorios que almacenan y buscan en persistencia; y todo esto sin modificar absolutamente nada del dominio.

Si diseñas primero la base de datos lo estás haciendo MAL y mal te saldrá la aplicación.

jueves, 22 de enero de 2015

Un blog maravilloso.



Muerto de sana envidia me encuentro con el descubrimiento de este blog que sólo puedo calificar de maravilloso.

Me encantaría tener la capacidad, los conocimientos y el sentido común de Marco Di Stefano para conseguir que mis entradas en este blog se parezca mínimamente al suyo.

http://www.refactoringideas.com/

Y este otro tampoco tiene desperdicio.

http://www.sapiensworks.com/blog/

jueves, 8 de enero de 2015

Arquitecura de Android SOLID(A) III

El controlador

En este ejemplo el controlador es extremadamente sencillo y puede que carezca de sentido pero pensad que en una aplicación real tendríamos, además de la modificación del modelo y del modelo de vista, lógica de aplicación, coordinación y orquestación de servicios, acceso a persistencia, etc.

El controlador es invocado por la vista y contiene la lógica para modificar el modelo y el modelo de vista en caso de ser necesario.


lunes, 5 de enero de 2015

Arquitecura de Android SOLID(A) II

El Modelo de Vista

El Modelo de Vista representa el estado de los componentes de la vista. Contiene variables que representan el estado de los controles como su visibilidad, si están activos, chequeados, si debe tener un color de fondo u otro, etc.

La lógica que encapsula el MV es la toma decisiones con respecto a la interfaz de usuario dependiendo de el Modelo y/o el estado de otros controles.

Por ejemplo, el MV podría contener el código y los estados que controlan si una lista desplegable se debe activar o desactivar dependiendo de si el usuario ha activado un checkbox y además cambia de color el fondo de una caja de texto para que al usuario no se olvide de rellenarla. Ofreciendo una función al controlador que tendría esta pinta :