UNIVERSIDAD NACIONAL DE EL SALVADOR FACULTAD MULTIDICIPLINARIA DE OCCIDENTE

BASE DE DATOS 2012

UNIVERSIDAD NACIONAL DE EL SALVADOR FACULTAD MULTIDICIPLINARIA DE OCCIDENTE

BASE DE DATOS 2012

NHYBERNATE

Nhibernate, Motor de persistencia Puesto a que este mundo es muy cambiante debemos estar al tanto de las diferentes tipos de tecnologías que vienen saliendo al campo informático. Herramientas que van a facilitar la vida de cualquier programados, analista de base de datos, administrador de red, en fin en este campo tan variado y complicado que es la informática. Con este trabajo daremos a conocer una de las tantas tecnologías nuevas en las que el campo de programación va avanzando y mejorando para lograr hacer la vida de dichos más fácil.

NHibernate es la conversión de Hibernate de lenguaje Java a C# para su integración en la plataforma .NET. Al igual que muchas otras herramientas libres para esta plataforma, NHibernate también funciona en Mono.

Al usar NHibernate para el acceso a datos el desarrollador se asegura de que su aplicación es agnóstica en cuanto al motor de base de datos a utilizar en producción, pues NHibernate soporta los más habituales en el mercado: MySQL, PostgreSQL, Oracle, MS SQL Server, etc. Sólo se necesita cambiar una línea en el fichero de configuración para que podamos utilizar una base de datos distinta.

Qué es un motor de persistencia?

Los motores de persistencia, que en el mundo de la programación no es más que un

componente de software (una capa de programación), también conocido como “capa de datos”, “capa de persistencia” o “correspondencia O/R (“OR mapping”)”, son los que permiten establecer una capa intermedia entre el sistema orientado a objetos y la base de datos relacionales donde se almacenarán toda la información del mismo.

Esta solución brinda las mejores ventajas de ambos modelos:

Por una parte, se puede programar con orientación a objetos, aprovechando las ventajas de flexibilidad, mantenimiento y reusabilidad.

Por otra parte, el poder usar una base de datos relacional, aprovechándose de su

madurez, la estandarización y las herramientas relacionales que hay para ella.

En la actualidad existen distintos tipos de motores de persistencia. Entre los de código

abierto se pueden destacar: Hibernate, Castor, Torque, OJB y Cayenne. Entre los comerciales, se pueden nombrar: TopLink, Cocobase y FastObjects. En los últimos años se ha creado una especificación llamada JDO, para estandarizar la forma de programar en Java con esos motores de persistencia. Ejemplos de motores de persistencia que cumplen

UNIVERSIDAD NACIONAL DE EL SALVADOR FACULTAD MULTIDICIPLINARIA DE OCCIDENTE

BASE DE DATOS 2012

el estándar JDO son Kodo, JDO Genie, LiDo, Exadel JDO, IntelliBO, JRelay JDO (todos ellos comerciales), Speedo JDO, TJDO y XORM (de código abierto).

NHibernate

En .NET los datos se representan en objetos. Sin embargo, las bases de datos habituales (como Oracle, SQL Server) guardan sus datos en forma relacional. Evidentemente existe una brecha entre estos dos mundos ("objetos-relacional") que, de alguna manera, debe completarse.

Los frameworks que se encargan de adaptar el mundo de objetos al relacionan son conocidos como ORM (Object-RelationalMapping). Existen varios ORM en el mercado.

NHibernate se encarga, justamente, de relacionar clases con tablas. A forma muy simple, una tabla se mapea contra una clase, y cada columna contra un atributo de dicha clase.

De esta forma, NHibernate se encargará de ocultar la complejidad del acceso a datos, exponiendo solamente objetos. Idealmente, en una aplicación con NHibernate, no es necesario generar querys SQL para interactuar con los datos (de hecho, la aplicación no tiene contacto directo con la base de datos).

Los mapeos

Como dijimos, las tablas a usar se mapean contra clases. Es decir, tendremos que establecer cuál es la relación entre cada tabla y cada clase, y cuál es la relación entre cada

columna con cada atributo de clase. Con NHibernate, estos mapeos pueden escribirse en archivos XML o utilizando anotaciones. En este curso vamos a usar anotaciones para realizar los mapeos, ya que en términos generales es una implementación más sencilla y rápida para desarrollar y mantener.

ARQUITECTURA DE NHYBERNATE

la aplicación trabaja con objetos persistentes, pero sin comunicarse directamente con la base de datos. En su

lugar, la comunicación será con elframework Nhibernate, el cual se compone de una sección de configuración según nuestro proyecto sea Windows Forms o Web) y un conjunto de mapeos Objeto-Relacionales. Utilizando estos elementos, Nhibernate se comunicará con la base de datos y realizará las acciones requeridas por los objetos persistentes (inserción, actualización, borrado, selección).

UNIVERSIDAD NACIONAL DE EL SALVADOR FACULTAD MULTIDICIPLINARIA DE OCCIDENTE

BASE DE DATOS 2012

ARQUITECTURA LIJERA

Entrando un poco más en detalle, una arquitectura “ligera” de NHibernate es cuando la

aplicación proporciona sus propias conexiones ADO.NET

Los objetos persistentes requieren almacenar estados, para esto es necesario utilizar una

sesión (canal de comunicación entre la aplicación y la base de datos).

La sesión de comunicación será creada por una SessionFactory, que es un caché de los

mapeos de una base de datos en particular. La SessionFactory puede ser configurada

utilizando código o configurando los archivos App.config o Web.config

UNIVERSIDAD NACIONAL DE EL SALVADOR FACULTAD MULTIDICIPLINARIA DE OCCIDENTE

BASE DE DATOS 2012

ARQUITECTURA COMPLETA

Ahora, si deseamos utilizar todas las características que provee NHibernate, podemos

utilizar una arquitectura completa como la que se muestra

En esta arquitectura, NHibernate provee lo que es el control de transacciones (utilizando

Transactions creadas por una TransactionFactory) y control de conexiones ADO.NET que

no están expuestas a la aplicación, sin embargo pueden ser extendidas o implementadas

por los desarrolladores

En detalle algunas de las partes de esta arquitectura

SessionFactory

Un caché threadsafe (inmutable) de mapeos compilados para una sola base de datos. Una

fábrica de Session y un cliente de ConnectionProvider, SessionFactory puede mantener un

UNIVERSIDAD NACIONAL DE EL SALVADOR FACULTAD MULTIDICIPLINARIA DE OCCIDENTE

BASE DE DATOS 2012

caché opcional (de segundo nivel) de datos reusables entre transacciones a nivel de

proceso o de clúster.

Session

Un objeto mono-hebra, de corta vida que representa una conversación entre la aplicación

y el almacenamiento persistente. Envuelve una conexión JDBC y es una fábrica

de Transaction. Sessionmantiene un caché requerido de primer nivel de objetos

persistentes, que se utiliza cuando se navega el gráfico de objetos o mientras se buscan

objetos por identificador.

Objetos y colecciones persistentes

Objetos de corta vida, mono-hebra contienen un estado persistente así como una

funcionalidad empresarial. Estos pueden ser JavaBeans/POJOs normales. Estos se

encuentran asociados con exactamente una Session. Tan pronto como la Session se cierre,

serán separados y estarán libres para utilizarlos en cualquier capa de aplicación, (por

ejemplo, directamente como objetos de transferencia de datos hacia y desde la

presentación).

Objetos y colecciones transitorios y separados

Instancias de clases persistentes que no se encuentran actualmente asociadas con

una Session. Pueden haber sido instanciadas por la aplicación y aún no haber sido

persistidas, o pueden haber sido instanciadas por una Session cerrada.

Transaction(Opcional)

Un objeto de corta vida, mono-hebra que la aplicación utiliza para especificar unidades

atómicas de trabajo. Abstrae la aplicación de las transacciones subyacentes JDBC, JTA o

CORBA. En algunos casos, una Session puede extenderse sobre varias Transactiones. Sin

embargo, la demarcación de la transacción, ya sea utilizando la API subyacente

o Transaction, nunca es opcional.

ConnectionProvider (Opcional)

UNIVERSIDAD NACIONAL DE EL SALVADOR FACULTAD MULTIDICIPLINARIA DE OCCIDENTE

BASE DE DATOS 2012

Una fábrica y pool de conexiones JDBC. Abstrae a la aplicación

del Datasource oDriverManager subyacente. No se expone a la aplicación, pero puede ser

extendido/implementado por el desarrollador.

TransactionFactory (Opcional)

Una fábrica de instancias de Transaction. No se expone a la aplicación pero puede ser

extendido/implementado por el desarrollador.

Extension Interfaces

Hibernate ofrece un rango de interfaces de extensión opcionales que puede implementar

para personalizar el comportamiento de su capa de persistencia. Para obtener más

detalles, vea la documentación de la API.

Transitorio

La instancia no está asociada con un contexto de persistencia. No tiene identidad

persistente o valor de clave principal.

Persistente

La instancia se encuentra actualmente asociada con un contexto de persistencia. Tiene

una identidad persistente (valor de clave principal) y puede tener una fila correspondiente

en la base de datos. Para un contexto de persistencia en particular,

Hibernate garantiza que la identidad persistente es equivalente a la identidad Java en

relación con la ubicación del objeto.

Separado

La instancia estuvo alguna vez asociada con un contexto de persistencia, pero ese

contexto se cerró, o la instancia fue serializada a otro proceso. Tiene una identidad

persistente y puede tener una fila correspondiente en la base de datos. Para las instancias

UNIVERSIDAD NACIONAL DE EL SALVADOR FACULTAD MULTIDICIPLINARIA DE OCCIDENTE

BASE DE DATOS 2012

separadas, Hibernate no establece ninguna garantía sobre la relación entre identidad

persistente e identidad Java.

CONFIGURACION NHYBERNATE

Existen varias formas de configurar la comunicación entre NHibernate y la base de datos,

sin embargo la más recomendable es utilizar un archivo App.config (configuración de

proyecto) ya que permite cambiar la configuración de acceso sin cambiar el código de la

aplicación en sí.

Un archivo de configuración de aplicaciones es un archivo XML que permite configurar

algunas opciones específicas de la aplicación que desarrollamos. La estructura básica del

archivo de configuración App.config es la siguiente.

En la zona de configuración es posible agregar las configuraciones específicas para cada

aplicación utilizada en la solución actual. En este caso es necesario configurar las opciones

de NHibernate para que acceda a la base de datos utilizada. A continuaciónun ejemplo de

la configuración de NHibernate para acceder a una base de datos

UNIVERSIDAD NACIONAL DE EL SALVADOR FACULTAD MULTIDICIPLINARIA DE OCCIDENTE

BASE DE DATOS 2012

Donde se debe reemplazar los valores XXX, YYY y ZZZ según sea la base de datos que

estemos utilizando para almacenar los datos de nuestra aplicación.

La versión 1.2 de Nhibernate soporta las bases de datos más utilizadas hoy en día

Microsoft SQL Server 2000

•XXX: MsSql2000Dialect

•YYY: SqlClientDriver

•ZZZ: “Server=dbServer;Initial catalog=db;Integrated Security=SSPI”

Microsoft SQL Server 2005

• XXX: MsSql2005Dialect

•YYY: SqlClientDriver

• ZZZ: Server=Server;Database=EjemplosNHibernate;User Id=usuario;Password=pwd

MySQL

•XXX:MySQLDialect o MySQL5Dialect (MySQL 5)

•YYY: MySqlDataDriver

•ZZZ:“Server=server;Database=database;User ID=user; Password=password”

Oracle

•XXX: OracleDialect / Oracle9Dialect

•YYY: OracleClientDriver

•ZZZ:“Data Source=fuente;User Id=user;Password=pwd;”

PostgreSQL

•XXX: PostgreSQLDialect

•YYY: NpgslDriver

•ZZZ: “Server=Server;Database=db;User id=user; Password=pwd;Encoding=UNICODE”

UNIVERSIDAD NACIONAL DE EL SALVADOR FACULTAD MULTIDICIPLINARIA DE OCCIDENTE

BASE DE DATOS 2012

Teniendo la configuración del archivo App.config definida, sólo nos queda obtener el

driver necesario para la conexión y agregar una referencia a él en nuestro proyecto.

•SQL Server 2000-2005:

System.Data.SqlClient en System.Data.dll (VS2005).

•MySQL:

http://dev.mysql.com/downloads/connector/net/1.0.html

•Oracle:

System.Data.OracleClient.dll (en VS2005).

•PostgreSQL:

http://pgfoundry.org/projects/npgsql/Introducción a NHibernate 8