Empezando con NHibernate

Desde que Microsoft empezó a divulgar Linq2SQL y Entitity-Framework la cantidad de empresas y programadores que usan NHibernate aumentó notablemente. Quiero aprovechar la ocasión para intentar definir algunas líneas guías que ayuden a iniciarse con NHibernate (NH para los amigos).

En este post empiezo… despacito iremos avanzando juntos.

¿Qué es NHibernate?

NHibernate es un framework de persistencia basado en ORM (Object Relational Mapping).

Que NH se base en ORM significa que conocer la técnica de ORM es fundamental, no es una opción.

En la red se pueden encontrar varios recursos sobre ORM, a mi gusto, los mejores son los escritos por Scott Ambler. Si piensan no tener tiempo de leer "Agile Database Techniques" no hay problemas pero no se pierdan una de sus White-paper que subí en los files de varios fórums.

Que NH sea un framework de persistencia significa que tienen que pensar en NH como algo que ejecuta queries SLQ (ejecuta INSERT, UPDATE, DELETE, SELECT). NH simplifica el acceso a datos y NO debería tener mayores responsabilidades que eso. Si entendieron esta simple definición entenderán que preguntas como "¿puedo usar NH con WPF?" o "¿NH funciona con WCF?" o "¿Hay algo para usar NH en WinForm?" son preguntas con muy poco sentido porque sería como preguntarse si pueden usar una clases de ejecute queries en cada uno de esos ambientes.

Tal vez una definición más cercana a la realidad es: NHibernate es un DAL (Data Access Layer).

Las técnicas de ORM nacieron exactamente para abstraer el acceso a DataBase relacionales en una capa que resuelva el acceso a datos. Lo que hay que tener en cuenta, en esta afirmación, es la palabra capa (Layer). En este caso "capa" identifica un estrato lógico de nuestra aplicación. Nuestra aplicación será completamente orientada a objetos (entidades de negocio) y nuestro DAL se ocupará de transformar esos objetos en instrucciones SQL para gestionar el estado persistente (los datos de cada entidad de negocio que nuestra aplicación deberá recordar).

De aquí naces algunas recomendaciones:

• No intenten usar NH en una aplicación que no esté bien dividida en capas lógicas.
• No hagan comparaciones entre usar ADO.NET, con data-binding, con usar NH; sería como paragonar un auto terminado con un motor.
• No piensen en tabla-fila-columna; piensen, primeramente, en entidades de negocio, propiedades y relaciones.
• Nunca olviden que todo termina en una base de datos relacional; empezar con objetos y pensar OO no significa que tengamos que olvidarnos que el data base existe.
• Empiecen definiendo las clases y, con la ayuda de un DBA, definan su representación persistente (siguiendo las reglas de ORM) y luego definan el mapping. En mi caso personal yo suelo definir la representación persistente directamente escribiendo el mapping.
• Usen como mínimo SchemaValidator y comparen siempre el schema que generaría NH con el schema que definieron ustedes.
• Escriban behavior-tests de persistencia y controlen las SQL generadas por NH.