Páginas

viernes, 30 de agosto de 2013

Ejemplo lista de tareas con Marionette

Marionette
Como comentaba en el ejemplo de una aplicación de una lista de tareas en una aplicación javascript Backbone es una herramienta que nos puede ayudar mucho a evitar que el código se nos convierta en difícil de manejar facilitándonos como estructurarlo con los modelos, colecciones y vistas y permitiéndonos separar el modelo de la vista actualizando estas últimas a través de los eventos que produce el modelo y escuchados en las vistas.

Backbone es una herramienta que nos da bastante libertad en cuanto a como queremos hacer las cosas y de lo que ofrece podemos usar solo lo que queramos. En algunos casos podemos considerar que Backbone ya es de por si una solución suficiente pero pero en otros podemos necesitar algo que nos facilite la tarea un poco más, de hecho hay muchas herramientas de terceros que proporciona multitud de funcionalidades adicionales sobre Backbone.

Usando Backbone por si solo a medida que vayamos haciendo varias aplicaciones nos daremos cuenta que debemos escribir código que empezaremos a considerar repetitivo, tampoco nos ayudará en desasociar los modelos de las vistas cuando eliminemos estas de la aplicación y si no lo hacemos correctamente tendremos fugas de memoria o vistas zombies que siguen escuchando eventos de los modelos cuando esperamos que se hubiesen destruido, también debemos encargarnos de gestionar donde deben visualizarse las vistas. Marionette es una de esas herramientas que nos puede ayudar a facilitarnos las tareas anteriores que en Backbone debemos hacer manualmente, además de ofrecernos algunas otras funcionalidades adicionales, pero también sin obligarnos a usar lo que no queramos siguiendo la misma filosofía de Backbone.

En esta entrada implementaré el mismo ejemplo de la lista de tareas que hice con Backbone pero esta vez implementado con Marionette aunque revisándolo incluiré un par de funcionalidades adicionales como externalizar del html las plantillas de las vistas y como internacionalizar los textos que aparecen en ellas si necesitamos soportar múltiples idiomas. Para ello utilizaré una de las versiones «bundled» que ofrece Marionette y un par de dependencias que necesita (wreq y babysiter).

El modelo y la colección de tareas es muy parecido aunque se han simplificado un poco al moverse el moverse el código que convertía el modelo a json a la vista, donde Marionette ofrece y llama al método serializeData cuando necesita y posteriormente el método render con los datos obtenidos, en el método render en definitiva se usa Mustache para producir el html de la vista. En realidad, el convertir el modelo al json que necesita a la vista está mejor colocado en la vista, ya que la vista es la que conoce los datos que necesita mostrar del modelo. Otra cosa muy útil que nos ofrece Marionette es la sección con los elementos ui de las vistas, esto evitará que tengamos los sectores de jquery repartidos por varios sitios de la vista y hará el código más simple y legible. Las secciones de las vistas modelEvents y collectionEvents sirven para los mismo que hacíamos en el método initialize con .on o .listenTo de Backbone.

Los objetos Marionette.ItemView sirven para visuaslizar un modelo (una tarea) y Marionette.CollectionView sirve para mostrar una colección de elementos (una lista de tareas). El objeto Marionette.Layout se utiliza para componer una vista con varias secciones (tareas y estado) donde podremos colocar las vistas de la aplicación, aparte de estas secciones un Layout es como una vista Marionette.ItemView con su plantilla. Con Marionette.Controller construiremos una clase que podemos utilizar para ofrecer la interfaz de la aplicación al exterior del módulo con únicamente los métodos necesarios (sin initialize, render y los métodos onXxx del mismo ejemplo con Backbone). Y hasta aquí, son los cambios más importantes en cuanto al cambio de Backbone a Marionette.

A continuación el código del módulo tareas que contiene la mayor parte del código javascript de la aplicación y el módulo main que no cambia en nada.

Para externalizar las plantillas del html podemos usar el plugin de RequireJS text que permite cargar el contenido de archivos como dependencias de un módulo tal como sucede como los archivos javascript. Y para internacionalizar las cadenas de las plantillas el plugin i18n. Los literales de cada idioma se definen en un archivo distinto, en el caso de esta aplicación solo he proporcionado uno, para el idioma inglés en la carperta src/main/webapp/js/i18n/nls/en, cada uno de estos archivos contiene una clave/valor, algunos de los cuales son una plantilla de Mustache para sustituir las variables como en «{{completadas}} tareas de {{total}} completadas». A continuación el código de un plantilla de Mustache que se carga de forma externalizada y el archivo con los literales que se utilizarán en la localización por defecto. Estos dos plugins de RequireJS probablemente nos sean necesarios y útiles en un ejemplo real.

El idioma de la aplicación se especifica en el archivo que genera el html de la página.

La aplicación tiene el siguiente aspecto:


Para terminar y como prólogo de la siguiente entrada un detalle que comentaré es la cantidad de archivos que se cargan para este ejemplo y eso que no es excesivamente complejo, en total al cargar el ejemplo se hacen 31 peticiones, unas cuantas son de los estilos, fuentes e imágenes pero la mitad son de archivos js y plantillas mustache. En la siguiente entrada explicaré como optimizarlo para conseguir reducir esas 31 peticiones a 13, con una diferencia importante de tiempo de carga y esto en local (probablemente puesto el ejemplo en internet la latencia y la diferencia sería mayor), también conseguiremos reducir algunos kilobytes de peso a la página. La optimización será similar a lo que explique en la Optimización de módulos RequireJS y archivos javascript del ejemplo más sencillo de la Introducción a Backbone pero aplicado a este ejemplo de Marionette que es bastante más complejo. En el código fuente puede verse también como ejecutar pruebas unitarias usando Grunt, Jasmine, Sinon y como integrarlo con Gradle pero la expicación de esto será tema para otra entrada.

Como en el resto de entradas el código fuente completo lo puedes encontrar en mi repositorio de GitHub. Si quieres probarlo en tu equipo lo puedes hacer de forma muy sencilla con los siguientes comandos y sin instalar nada. Si no dispones de git para clonar mi repositorio de GitHub puedes obtener el código fuente del repositorio en un archivo zip con el anterior enlace.

Referencia:
Introducción y ejemplo de RequireJS
Introducción y ejemplo de Mustache
Logging en Javascript con log4javascript
Capturar errores de Javascript
Optimizar módulos de RequireJS y archivos Javascript
Patrón de diseño MVC del lado cliente con Backbone.js
Introducción y ejemplo de Backbone.js
Ejemplo de pruebas unitarias en javascript con Jasmine y Sinon
Backbone
Marionette

sábado, 24 de agosto de 2013

Ejemplo del patrón de diseño State

Java
Un patrón de diseño aplicado adecuadamente para resolver un problema puede ayudar enormemente a simplificar el código y facilitar el mantenimiento. Si tenemos un código que es difícil de mantener y entender, hay código duplicado y no tiene ninguna organización puede que aplicar un patrón de diseño nos resuelva el problema en gran parte.

Hace ya un tiempo comente cuales son los principales patrones de diseño y hice una entrada con un ejemplo del patrón de diseño Command. En esta entrada pondré un ejemplo del patrón de diseño State.

El patrón de diseño State nos puede ser de mucha utilidad en los casos que por ejemplo una entidad tenga asociado un grafo de estados con transiciones permitidas y no permitidas entre algunos estados. En función del estado, sus datos y la transición la entidad puede comportarse de forma diferente. Por ejemplo, supongamos que tenemos una entidad Compra que a lo largo de su vida en la aplicación pasa por diferentes estados:
  • creada: la compra se acaba de crear.
  • en espera: se ha hecho una compra y se está esperando que el pago sea correcto.
  • verificada: el pago es correcto y se está esperando a enviar el producto.
  • cancelada: la compra se ha cancelado porque el usuario no quiere ya el producto, no hay existencias u otro motivo.
  • enviada: el pedido ha sido enviado.
Y tiene diferentes transiciones como:
  • comprar: la compra pasa de creada a en espera de verificarla.
  • verificar: la compra pasa de en espera a verificada y esperando a enviarse.
  • cancelar: la compra se puede cancelar excepto una vez que ya se ha enviado.
  • enviar: la compra se envía al usuario y ya no puede cancelarse.
Diagrama de estados

Si diseñamos este flujo de estados sin el patrón State probablemente acabemos con una clase con un montón de condiciones y métodos de bastantes líneas sin una organización clara a simple vista. Para evitarlo aplicaremos el patrón State a este pequeño flujo de estados. En cuanto a código este patrón se basa en dos ideas:
  • Cada estado será representado una clase.
  • Cada una de estas clases contendrá un método por cada posible transición.
Y estas dos simples ideas son suficientes para guiar la tarea de codificación. Por lo tanto tendremos los siguientes clases que representarán a los estados: CreadaCompraState, EnEsperaCompraState, VerificadaCompraState, CanceladaCompraState y EnvidaCompraState.


Según el diagrama de estados y transiciones no todas las transiciones son posibles, una compra en espera no puede enviarse. Pero en el código estamos haciendo que todos los estados tengan todos los métodos que representan todas las transiciones, la forma de hacer en el código que una transición no sea posible para un determinado estado es lanzando una excepción en su correspondiente método, el método enviar del estado en espera, lanzará una excepción ya que es este estado aún la compra no puede enviarse. La clase abstracta AbstractState implementará la interfaz CompraState y lanzará una excepción en todos los métodos, las clases que extiendan de esta podrán redefinir los métodos que necesiten utilizando la propiedad de la programación orientada a objetos del polimorfismo, esta clase abstracta nos permitirá implementar en cada clase de estado únicamente los métodos con las transiciones válidas. Las clases nos podrían quedar de la siguiente forma:

Para que los métodos puedan acceder y manipular los datos de la compra se les pasa como parámetro en el constructor. La factoría CompraStateFactory encapsula la lógica para construir cada uno de los estados. La implementación de cada uno de los estado podría ser la siguiente.

Finalmente, la clase Compra podría ser de la siguiente forma:


El patrón State puede facilitarnos bastante la vida como programadores pero si el diagrama de estados fuese más complejo, con mucha lógica de negocio y el flujo dependiense de información independiente de la compra quizá deberíamos evaluar su si un motor de procesos (BPMS) como Activiti y un sistema de reglas de negocio (BRMS) como Drools sería más adecuado.

El código fuente completo de ejemplo los puedes obtener de mi repositorio de github con los siguiente comandos:

Referencia:
Patrones de diseño en la programación orientada a objetos
Ejemplo del patrón de diseño Command y programación concurrente en Java
Ejemplo del patrón de diseño No Operation

viernes, 16 de agosto de 2013

Pruebas unitarias de código que accede a base de datos

Hibernate
Una de las dificultades que nos solemos encontrar a la hora de hacer pruebas unitarias es como probar el código que accede a la base de datos. El problema es que ese código necesita de una base de datos para ejecutarse, si se usa una base de datos como MySQL o PosgreSQL más que una prueba unitaria puede considerarse una prueba de integración y las pruebas pasan a depender de ese sistema externo con lo que las pruebas no son autónomas.

La base de datos H2 es una base de datos que puede ser embebida en una aplicación. Esta característica hace que pueda servir como base de datos contra la que lanzar los teses sin necesidad de una base de datos externa, además puede ejecutarse en memoria y sin comunicación de red lo que hace que sea muy rápida y los teses también. Tampoco es una solución perfecta ya que H2 puede tener un comportamiento diferente de la base de datos real pero en la mayoría de los casos nos servirá perfectamente.

Siguiendo los artículos anteriores en los que explicaba como acceder a una base de datos en una aplicación Java «standalone» y como hacer búsquedas en entidades de comino usando sin utilizar likes veamos como sería hacer una prueba unitaria de ese código que accede a la base de datos usando JUnit.

El método beforeClass inicializa la persistencia y crea el DAO. El método before borra los datos que haya creado un test anterior y crear los datos de prueba que una prueba puede esperar que existan, en este caso se trata de un único producto. Las pruebas consisten en probar el método findAll y search del DAO (el método removeAll puede considerarse probado en el before aunque podría crearse un caso de prueba específico):

En las pruebas unitarias al código que use el DAO puede proporcionársele un «stub» de este haciendo que devuelva los datos que necesitemos y sin necesidad de una base de datos como H2 pero para probar el DAO hay que disponer de una base de datos. Como es código que también puede contener fallos es bueno que también esté cubierto con algunas pruebas. Con Hibernate todo será más sencillo ya que con este además de abstraernos de la base de datos específica puede crear el esquema con las tablas y campos a partir del modelo de forma que antes de pasar los teses no necesitemos lanzar un script con sentencias SQL para crear las tablas.

Usar H2 como la base de datos contra que lanzar las pruebas unitarias es una solución imperfecta ya que idealmente la base de datos debería ser igual a la base de datos que vaya a usar la aplicación real (probablemente MySQL o PosgreSQL). H2 tiene la ventaja de que los teses se ejecutarán más rápido que con un sistema real externo y que las pruebas son más autónomas ya que no depende de ese sistema externo, aún así si hacemos uso de elementos nativos de la base de datos y queremos que queden cubiertos con pruebas no nos quedará más remedio que disponer de una base de datos «más real» que H2 para ellas aunque como decía estas pasarán a ser más de integración que unitarias.

Como el resto de ejemplos que escribo en el blog el código fuente lo puedes encontrar en mi repositorio de GitHub. Para probar este código en tu equipo basta con ejecutar:

Referencia:
Código fuente acceso a base de datos con Hibernate y JPA http://stackoverflow.com/questions/82949/before-and-after-suite-execution-hook-in-junit-4-x

viernes, 9 de agosto de 2013

Búsquedas de texto completo en objetos de dominio

Hibernate
Si hace un tiempo hablaba de un problema muy común que nos encontramos al desarrollar una aplicación como los es internacionalizar los textos de algunos campos de una entidad de dominio, el hacer búsquedas de texto completo sobre esos campos más allá del like que nos ofrece el lenguaje SQL de las base de datos también es un problema a resolver.

La primera solución que se nos puede ocurrir es hacer las búsquedas empleando el like del lenguaje SQL de la base de datos relacional que usemos. Sin embargo, el like de SQL tiene varias limitaciones y además es lento, supone una carga para la base de datos y las coincidencias son muy limitadas no teniendo en consideración peculiaridades del idioma como tildes y aproximaciones. Para tratar de resolver estos problemas podemos usar la librería Hibernate Search que a partir de las clases de dominio y de las propiedades sobre las que queramos hacer búsquedas creará un indice de Lucene para realizar búsquedas más rápidamente y con mejores resultados.

Hibernate Search
Con Hibernate Search que se apoya en Lucene podemos obtener resultados que son aproximaciones a la palabra búsqueda, por ejemplo, si buscamos «refactor» podemos obtener coincidencias para las palabras «refactors», «refactored» y «refactoring» en el lenguaje inglés. Cada lenguaje tiene sus propias reglas de análisis para buscar estas aproximaciones y hay analizadores para la mayoría de lenguajes. Además, podemos obtener una aproximación de las coincidencias encontradas totales al estilo de como hace Google.

Continuando el ejemplo de como usar Hibernate en una aplicación «standalone» vamos a ver que hay que hacer para crear el índice y como realizar una búsqueda empleando Hibernate Search.

SQL
Otra alternativa a Hibernate Search es si la base de datos soporta «full text search», es decir, el motor de la base de datos soporta en la sintaxis de las sentencias SQL búsquedas de texto completo. En MySQL es posible pero hasta la versión 5.5 solo si la tabla está definida con MyISAM aunque a partir de la versión 5.6 es posible hacerlo con InnoDB que es el modelo de almacenamiento recomendado. La sintaxis de la sentencia SQL para MySQL sería:

En PostgreSQL la sintaxis «full text search» es diferente:


Aunque con soluciones específicas del motor de la base de datos como esta perdemos la abstracción de la base de datos que proporciona Hibernate nos evitamos el tener que mantener el índice de Lucene con Hibernate Search.

Elasticsearch
Otra posibilidad muy interesante y tan buena o mejor que las anteriores es utilizar elasticsearch aunque al igual que con Hibernate Search debamos mantener e índice y los datos sincronizados pero eso probablemente sea tema para otra entrada :).

Referencia:
Código fuente búsqueda con Hibernate Search
Internacionalización (i18n) de campos con Hibernate
http://wiki.apache.org/solr/LanguageAnalysis
http://eraunatonteria.wordpress.com/tag/full-text-search/
http://dev.mysql.com/doc/refman/5.0/es/fulltext-search.html

viernes, 2 de agosto de 2013

Acceso a base de datos con Hibernate y JPA

Hibernate
Si usamos Hibernate como la capa de persistencia de nuestra aplicación es muy probable que lo usemos a través de una aplicación web. Sin embargo, en algún caso como una migración de datos, la generación de algún informe o extracción de datos que no queramos o no nos sea posible hacerla en la aplicación web por el tiempo que tarda o la carga que supone para la aplicación web nos puede interesar usar Hibernate desde una aplicación Java normal lanzada desde linea de comandos.

Para ello deberemos obtener el objeto Session si usamos hibernate directamente o el EntityManager si usamos hibernate a través de JPA. La API de JPA es una capa de abstracción para varias librerías de persistencia, ORM, similares a Hibernate. Si Hibernate nos abstrae de la base de datos, JPA nos abstrae del framework de persistencia que vayamos a usar de forma que podamos reemplazarlo por otro sin realizar ninguna modificación al código JPA. Si ya sabemos usar Hibernate usar JPA no nos supondrá mucha dificultad ya que JPA se basa en gran medida en Hibernate.

En el siguiente ejemplo se puede ver como obtener un EntityManager, eliminar todos los objetos y hacer una búsqueda.

En el ejemplo he usado un dao genérico que nos puede servir para cualquier tipo de entidad, aunque el dao contenga operaciones básicas como probablemente sean comunes a todas las entidades que tengamos nos será de gran utilidad. A continuación las anotaciones que debemos usar para la entidad a persistir, nada distinto de lo que haríamos en una aplicación web.

Si JPA no tuviese alguna funcionalidad que si tuviese hibernate desde JPA podemos obtener el objeto Session con el que acceder a la API de hibernate.

Ejecutando la aplicación HibernateJPA obtendremos lo siguiente en la consola:

Como comentaba usar Hibernate en una aplicación Java normal no será lo habitual pero este ejemplo es el primer paso para que explique con un ejemplo simple como resolver otro de los problemas que suele ser habitual en muchas aplicaciones que es como hacer búsquedas sobre los objetos de dominio y no me refiero a usar likes de SQL que tienen varias limitaciones aparte de ser lentas si la tabla de búsqueda tiene muchos registros sino usando Hibernate Search.

Para probar los ejemplos en tu equipo puedes hacerlo con los siguientes comandos:

Si te ha interesado esta entrada quizá también te interese como hacer internacionalización (i18n) de campos con Hibernate y como hacer búsquedas de texto completo en objetos de dominio.

Referencia:
Código fuente acceso a base de datos con Hibernate y JPA
http://docs.jboss.org/hibernate/core/3.6/quickstart/en-US/html/hibernate-gsg-tutorial-jpa.html
http://www.manning.com/bauer2/
http://www.apress.com/9781430219569