nHibernate y MVC.

En este momento no recuerdo cuanto tiempo ha pasado desde que deje de usar los Stored Procedures con el ADO como mecanismo de persistencia, solo sé que al descubrir el EF mi mundo cambio. Con el EF podía usar los SP pero ya no era la única forma de acceder a los datos.

Desde que empecé a trabajar con MVC descubrí el nHibernate, pero me resistía a cambiar nuevamente. Recientemente al incursionar en la versión 5 del MVC decidí darle la oportunidad y ver que podía ofrecerme…

 

Que es nHibernate?

Es un ORM o mapeador relacional de objetos, (con sus siglas en ingles). Nos ofrece un mecanismo sencillo de mapear entidades de dominio (objetos) con tablas en una base de datos, donde cada registro representa una entidad. El objetivo principal de esta biblioteca es liberarnos de la carga de codificar una y otra vez líneas para lograr la persistencia de los datos que contienen los objetos de nuestra aplicación.

Desde luego además del mapeo, obtenemos mecanismos de consulta que en combinación con los mecanismos de persistencia, hacen que nHibernate sea una muy versátil y robusta solución para trabajar con datos, disminuyendo el margen de errores de codificación.

 

Arquitectura.

Lo primero que llamo mi atención fue su arquitectura, ya que promueve la separación de partes (SOC) favorece el uso de patrones como el de la unidad de trabajo y el de Factory. Además emplea las mejores prácticas para aspectos como la configuración, el mapeo, la carga de datos y el cache de los mismos.

Si lo comparamos con el EF podemos decir que el objeto principal contiene el modelo, la configuración y además es la unidad de trabajo; por lo tanto no resulta tan liviano a la hora de usarlo como su contra parte nHibernate.

 

La solución a nuestros problemas.

Una vez que empecé a usar este Framework, pude confirmar que es la solución para la terrible carga de escribir el código de persistencia de datos en cada proyecto, que además podría incluso llegar a representar un cuarto o un tercio del tiempo de programación de todo el proyecto, pero sobre todo este código requiere depuración y testeo cada vez que hacemos algún cambio; con nHibernate esta parte ha sido superada casi en su totalidad.

Lo más impresionante es la rapidez con la que podemos hacer modificaciones en la base de datos que con algunas líneas queda completamente adaptado, con un mínimo o nada de testeo.

 

Como trabaja?

Se trata de un motor de persistencia y consultas; o sea se encarga de crear, actualizar y eliminar registros, así como de hacer consultas y mantener en cache los más recientes datos leídos de la base de datos.

Esto significa que al escribir nuestro código, usaremos propiedades sin tener que preocuparnos de hacer las traducciones en ambos sentidos, nHibernate envía o recupera la información, logrando que resulte muy sencillo y seguro para nosotros.

 

El modelo.

nHibernate nos ofrece dos enfoques para trabajar con él:

• Centrado en datos: empieza con el modelo desde la base de datos y crea los objetos.
• Centrado en objetos: empieza con el modelo desde las clases y crea las tablas.

Como ya debemos saber, el modelo de datos, no siempre coincide con el modelo de clases y viceversa. Cada enfoque presentara ciertos detalles que requerirán de nuestra intervención para lograra que se acoplen uno sobre el otro.

Yo prefiero el modelo centrado en los datos, o sea empiezo por diseñar la base de datos y a partir de esta creo los objetos y la descripción del mapeo que se requerirá.

 

Integración con MVC.

nHibernate encuentra una arquitectura ideal cuando se trata de MVC; su presencia se limitara al ámbito del Model. La configuración se realiza una sola vez en el proceso de carga de la aplicación; la conexión se abrirá al momento de recibir una solicitud y se cierra cuando el controller responde y la solicitud termina.

En la arquitectura de mis aplicaciones empleo las siguientes clases dentro del Model:

• Servicios: Estas clases se encargan de recibir las instrucciones del Controller y a su vez se comunican con los repositorios.
• Repositorios: Estas clases son las que interactúan con nHibernate y se encargan de la persistencia y las consultas.

La unidad de trabajo (la transacción) se crea a nivel de los servicios, esto me permite propagar una transacción entre varios repositorios, con una sola instrucción final. La comunicación entre las clases de las diferentes capas es limpia y muy fácil de implementar. Tal vez la única parte que podría parecernos complicada sea la configuración inicial, ya que el mecanismo original se realiza con XML.

 

XML o Fluent?.

El mapeo más estable y robusto del nHibernate es el que se hace usando XML, pero resulta muy complicado y no es validado por el compilador; en cambio si usamos el mecanismo Fluent podemos realizar declaraciones fuertemente tipificadas que son muy fáciles de entender y que además el compilador puede verificar; sin embargo este mecanismo aun no cubre todos los aspectos de asociación y de mapeo que podemos realizar usando el XML.

Sin embargo la buena noticia es que se encuentra en vías de desarrollo, por lo que pronto resultara ser el complemento perfecto para esta tecnología.

La biblioteca Fluent-nHibernate nos ofrece una alternativa a la manera standard usando XML. Nuestro código resultara más fácil al momento de refactorizar, mas fácil de leer y mucho mas conciso que si usamos el XML.

 

Como la podemos obtener?

Para usar este método, será necesario instalar además del nHibernate la biblioteca fluent-nHibernate, esto resulta muy fácil a través de NuGet..

Después será necesario realizar dos pasos:

1. Debemos hacer es añadir la palabra virtual a las propiedades que definen nuestras entidades, con esto permitimos que estas propiedades puedan ser sobre escritas en una clase derivada.
2. Debemos crear una clase que reciba el mismo nombre que nuestra entidad, pero que termine con la palabra MAP, esta clase debe heredar de la clase ClassMap<T> donde T es el tipo de nuestra entidad.

En futuros artículos les explicare con ejemplos como codificarlo, en este momento lo importante es que comprendan los conceptos relacionados.

Comentario final.

He cambiado el EF por el nHibernate y siento que mi programación es más rápida, mi código es más estable, los cambios al nivel de la base de datos, no son problema y suelen hacerse con tres líneas de código por cada campo que añadamos.

Con nHibernate (y un generador de código que cree para esta arquitectura) solo debo enfocarme en el código de negocios que es el más importante, ya que la persistencia es muy tediosa.

Suerte.