inmensia

El concepto de transacción es algo que cualquiera que haya trabajado con una base de datos debería comprender perfectamente. Se establece un punto de inicio, se realizan operaciones, y se termina consolidando las operaciones realizadas (con un commit), o deshaciéndolas (con un rollback). La transacción garantiza la atomicidad de las operaciones, o todo o nada.

Spring da soporte para incorporar la gestión de transacciones a las aplicaciones más allá del ofrecido por un gestor de base de datos. Ya sea aprovechando las capacidades ofrecidas por un servidor de aplicaciones, o las proporcionadas de forma local por la propia aplicación mediante alguna librería que lo implemente. En los siguientes artículos de la serie dedicada a Spring reviso algunos términos importantes y muestro configuraciones de ejemplos:

- Transacciones (1) - Introducción

- Transacciones (2) - Definición y Uso

- Transacciones (3) - Configuración y Anotaciones

- Transacciones (4) - Ejemplo

Una de las cosas que siempre me han gustado de esta parte es que basta con añadir la etiqueta @Transactional sobre un método para conseguir que su código se ejecute dentro de una transacción. Una de las cosas que nunca me han gustado de esta parte es que en algunos casos, si la configuración no es correcta, el código no se ejecuta dentro de una transacción, pero no se eleva ningún mensaje de advertencia o error ni se produce ninguna excepción.

La siguiente tanda de artículos estará dedicado al acceso a base de datos y el mapeo objeto relacional en general.

Hacer pruebas de una aplicación tradicional que ataque una base de datos siempre ha sido algo problemático, y si no, al menos algo laborioso. En esta nueva tanda de artículos dentro de la serie dedicada a Spring se enumeran algunas de las características concretas que ofrece el framework para ayudar en la creación de pruebas unitarias, de integración, y su uso con JUnit:

- Testing (1) - Tests Unitarios

- Testing (2) - Tests de Integración

- Testing (3) - JUnit

Desde que se popularizó el término TDD (Test Driven Development), o sea, escribir y ejecutar primero el código de pruebas antes que el código de producción, parece que no es correcto hablar de desarrollo de sofware sin mencionarlo. ¿Y además un 100% de cobertura? Uhmm... eso implica hacer pruebas hasta para los getters y setters.

El siguiente tema de la serie abordará la gestión integrada de transacciones.

He ampliado la serie de artículos dedicados a Spring con nuevas entradas introduciendo la programación orientada a aspectos, haciendo hincapié en los conceptos básicos, la nomenclatura declarativa propia de Spring, y proporcionando un ejemplo sencillo que sirva para futuras referencias:

- AOP (1) - Introducción

- AOP (2) - Poincuts y Advices

- AOP (3) - Schema

- AOP (4) - Ejemplo

La programación orientada a aspectos debería buscarse un experto en Marketing. Tiene cinco o seis conceptos claves, pero los términos que utiliza para designarlos resultan por lo general bastante confusos. De hecho, al principio es normal estar consultando cada poco la definición de los términos básicos, para saber de que se está hablando exactamente en un párrafo más o menos complicado.

No obstante, es una técnica muy potente que permite definir el comportamiento de un sistema sin modificar el código fuente del mismo. Algo básico para cumplir con uno de los objetivos de Spring, que es el de procurar ser lo menos intrusivo posible, y que posiblemente adopta su máxima expresión con herramientas como Spring Roo con su particular filosofía de funcionamiento.

La siguiente tanda de artículos serán una introducción a las características de soporte de Spring para la ejecución de pruebas.

He publicado un nueva tanda de artículos dentro de la serie dedicada a Spring. Esta vez unos cuantos temas sueltos referentes a los validadores y formateadores, binding y conversiones de tipos, así como un pequeño resumen de las capacidades de SpEL, el lenguaje para construir expresiones de Spring:

- Validadores

- Binding, Converter y Formatting

- SpEL (1): Expression Language

- SpEL (2): Expresiones Básicas

- SpEL (3): Expresiones Avanzadas

Normalmente hay ciertas características de Spring que se usan sin pensar más en ellas, como la forma de escribir las expresiones con las que se configura un sistema. Lo que se ignora a veces es que se puede utilizar el parser de expresiones de Spring dentro del código de las aplicaciones, como cualquier otro tipo de librería de utilidades.

La única forma de estar al tanto de estas cosas es estudiar toda la documentación oficial y probar en carne propia sus capacidades. Y en algunos casos, como el mío, ponerlas por escrito para futuras referencias. A veces es mejor leer un ejemplo escrito por uno mismo que mil escritos por otros.

En la siguiente tanda de artículos abordaré los temas específicos de la programación orientada a aspectos.

A pesar de haber trabajado en los últimos años con varios proyectos que utilizaban Spring, al revisar la documentación oficial de referencia siempre acaba encontrándose uno algo nuevo. Algún detalle perdido aquí y allá. Algún comentario de los desarrolladores. Alguna actualización de la librería.

He añadido a la serie de artículos sobre Spring nuevas entradas, dedicadas al uso de anotaciones y algunas características concretas del ApplicationContext:

- Anotaciones (1): Dependencias

- Anotaciones (2): Componentes

- Anotaciones (3): Configuración

- ApplicationContext (1): Internacionalización

- ApplicationContext (2): Eventos

- ApplicationContext (3): Recursos

Lo siguiente será un par de temas sueltos y una introducción a SpEL, el lenguaje para construir expresiones de Spring.