lunes, 14 de octubre de 2013

Spring: Mejorando el Trabajo con Hibernate ORM

Recorriendo Spring
Uno de los problemas con el uso de Hibernate es que la aplicación cliente que accede a la base de datos usando Hibernate Framework tiene que depender de la API de Hibernate como configuración, SessionFactory y Session. Estos objetos se encuentran dispersos por todo el código en la aplicación.

Por otra parte, el código de la aplicación tiene que mantener y gestionar manualmente estos objetos. En el caso de Spring, los objetos de negocio pueden ser altamente configurable, con la ayuda de la IOC.

 En pocas palabras, el estado de un objeto puede ser externalizado desde el código de aplicación, esto significa que ahora es posible utilizar los objetos Hibernate como bean de spring  y pueden disfrutar de todos los beneficios de Spring.

 Spring es un Framework  que desempeña diferentes papeles en muchas áreas de la arquitectura de la aplicación. Una de estas áreas es la persistencia, dado que Spring no proporciona su propio framework de persistencia. En su lugar, proporciona una capa de abstracción sobre JDBC, interacción con ORM en el marco de mapeo como  iBATIS SQL Maps, Hibernate, JDO, OJB Apache y Oracle TopLink.
Esta abstracción permite, la aplicación de acceso a datos de una manera manejables consistente.

Como mejora el trabajo con ORM ¿?

La Capa de abstracción de Spring  abstrae de la aplicación la fábrica de conexiones, la gestión de transacción, y gestiona las  excepciones que utiliza la tecnología de persistencia con la que estemos trabajando en nuestro proyecto.   
Spring proporciona IOC  y AOP, que se puede utilizar en la capa de persistencia, afectando las  transacciones de Hibernate de manera externa y proporciona un enfoque más potente y completo para la gestión de transacciones sin ensuciar el código de nuestro proyecto.

Pero donde trabaja en mi Proyecto ¿?

Spring se encuentra entre las clases de la aplicación y la herramienta de mapeo ORM, realiza transacciones, y gestiona los objetos de conexión. Traduce las excepciones de persistencia subyacente lanzadas por Hibernate, excepciones sin control significativos de tipo DataAccessException las cuales pueden o no ser capturadas.

Pero ya que estamos con el tema datos, cual seria un buen patrón de diseño para trabajar ¿?

 En lo personal creo que DAO + Service es una buena practica.

Patron Data Access Object: Aunque se puede obtener un objeto de sesión y conectarse a Hibernate en cualquier parte de la aplicación, se recomienda que todas las interacciones con Hibernate puede hacer sólo a través de distintas clases . Con respecto a esto, hay un patrón de diseño JEE , llamado el patrón DAO que es la moneda corriente en el desarrollo de acceso a datos.
De acuerdo con el patrón DAO , todas las operaciones persistentes se deben realizar a través de clases específicas , técnicamente llamados clases DAO . Estas clases se utilizan exclusivamente para la comunicación con el nivel de datos . 

 El propósito de este modelo es separar el código relacionado con la persistencia de la lógica de negocio de la aplicación, lo que hace que para el código más manejable y fácil de mantener , lo que le permite cambiar la estrategia de persistencia , sin cambiar las reglas de negocio o la lógica del flujo de trabajo.

El patrón DAO establece que debemos definir una interfaz DAO correspondiente a cada clase DAO . Esta interfaz DAO describe la estructura de una clase DAO , define todas las operaciones de persistencia que necesita la capa de negocio , y (en las aplicaciones basadas en Spring ) nos permite aplicar la IOC para separar la capa de negocio de la clase DAO.

Patron Service Facade:   En aplicaciónes de acceso a datos, el motivo de la fachada servicio siempre se utiliza en conjunto con el modelo DAO. Este patrón indica que el uso de un objeto intermedio, denominado objeto de servicio, entre todos los objetos de la capa de negocio y los objetos DAO. 

El objeto de servicio reúne los objetos DAO a ser gestionados como una unidad de trabajo. Tenga en cuenta que sólo se crea una clase de servicio para todos DAOs que se implementan en cada caso de uso.

La clase de servicio utiliza las instancias de interfaces de DAO para interactuar con ellos. Estas instancias se crean instancias de las clases concretas DAO por el contenedor IoC en tiempo de ejecución. Por lo tanto, el objeto de servicio no tiene conocimiento de los detalles de implementación reales DAO,  Independientemente de la estrategia de persistencia utiliza la aplicación (incluso si utiliza JDBC), es muy recomendable aplicar el DAO y los patrones de fachada servicio para lograr arquitecturas desacopladas y escalables.


Una Implementación común con Hibernate: En primera instancia la definición de la interface dao.

package com.packtpub.springhibernate.ch13;

import java.util.Collection;


public interface StudentDao {

 public Student getStudent(long id);

 public Collection getAllStudents();

 public Collection getGraduatedStudents();

 public Collection findStudents(String lastName);

 public void saveStudent(Student std);

 public void removeStudent(Student std);
}


El siguiente paso seria la definición de la implementacion dao que utiliza hibernate para realizar las operaciones.

 
package com.packtpub.springhibernate.ch13;

import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.Transaction;
import org.hibernate.HibernateException;
import org.hibernate.Query;

import java.util.Collection;

public class HibernateStudentDao implements StudentDao {

SessionFactory sessionFactory;

 public Student getStudent(long id) {
 Student student = null;
 Session session = HibernateHelper.getSession();
 Transaction tx = null;
 try {
  tx = session.beginTransaction();
  student = (Student) session.get(Student.class, new Long(id));
  tx.commit();
  tx = null;
 } catch (HibernateException e) {
   if (tx != null)
    tx.rollback();
   throw e;
 } finally {
  session.close();
   }
  return student;
 }

 public Collection getAllStudents(){
 Collection allStudents = null;
 Session session = HibernateHelper.getSession();
 Transaction tx = null;
 try {
  tx = session.beginTransaction();
  Query query = session.createQuery(
  "from Student std order by std.lastName, std.firstName");
  allStudents = query.list();
  tx.commit();
  tx = null;
 } catch (HibernateException e) {
   if (tx != null)
    tx.rollback();
   throw e; 
 } finally {
  session.close();
    }
  return allStudents;
 }

 public Collection getGraduatedStudents(){
 Collection graduatedStudents = null;
 Session session = HibernateHelper.getSession();
 Transaction tx = null;
 try {
  tx = session.beginTransaction();
  Query query = session.createQuery(
  "from Student std where std.status=1");
  graduatedStudents = query.list();
  tx.commit();
  tx = null;
 } catch (HibernateException e) {
  if (tx != null)
   tx.rollback();
  throw e;
 } finally {
  session.close();
    }
 return graduatedStudents;
 }

 public Collection findStudents(String lastName) {
 Collection students = null;
 Session session = HibernateHelper.getSession();
 Transaction tx = null;
 try {
  tx = session.beginTransaction();
  Query query = session.createQuery(
   "from Student std where std.lastName like ?");
  query.setString(1, lastName + "%");
  students = query.list();
  tx.commit();
  tx = null;
  } catch (HibernateException e) {
   if (tx != null)
    tx.rollback();
   throw e;
  } finally {
   session.close();
   }
  return students;
 }

 public void saveStudent(Student std) {
 Session session = HibernateHelper.getSession();
 Transaction tx = null;
 try {
  tx = session.beginTransaction();
  session.saveOrUpdate(std);
  tx.commit();
  tx = null;
  } catch (HibernateException e) {
   if (tx != null)
    tx.rollback();
   throw e;
  } finally {
   session.close();
  }
 }

 public void removeStudent(Student std) {
 Session session = HibernateHelper.getSession();
 Transaction tx = null;
 try {
  tx = session.beginTransaction();
  session.delete(std);
  tx.commit();
  tx = null;
  } catch (HibernateException e) {
   if (tx != null)
    tx.rollback();
   throw e;
  } finally {
   session.close();
   }
  }

 public void setSessionFactory(SessionFactory sessionFactory) {
  this.sessionFactory = sessionFactory;
 }
}

Como observación podemos notar en todos los métodos la utilización del manejo de transacciones, el trabajo con el objeto de session y la gestión de excepciones que realizamos en cada uno de los métodos.

 Nota: como observación final código repetido por todos lados.

 Patrón Template: Para limpiar el código y proporcionar más código manejable , Spring utiliza un modelo llamado patron Template . En este patrón, el objeto se encargara de todas las tareas repetitivas de nuestro codigo. En el caso Hibernate, HibernateTemplate extrae todo el código repetitivo , tales como la obtención de una sesión , la realización de la transacción , y la entrega de excepciones.

 Una implementacion de Hibernate con Spring : Con Spring tu no necesitas implementar código para la obtención del objeto de session,  gestionar las transacciones  y manejar las excepciones. Usaremos la instancia HibernateTemplate para delegar la persistencia de llamadas a  Hibernate, esta interaccionara directamente con Hibernate.

 Éstos son algunos de los beneficios de la utilización de Spring en la capa de persistencia, en lugar de usar la interacción directa con Hibernate:
  • Con Spring, el objeto HibernateTemplate interactúa con Hibernate. Este objeto se elimina el código repetitivo de las implementaciones de DAO.
  • Cualquier invocación de uno de los métodos de HibernateTemplate produce la excepción DataAccessException genérico en lugar de HibernateException (una excepción específica de Hibernate).
  • Spring nos permite delimitar transacciones declarativa, en lugar de implementar duplicado de código de gestión de transacciones. 
La clase HibernateTemplate usa una SessionFactory interno para obtener el objeto de session para interaccionar con Hibernate. Podremos configurar el objeto SessionFactory via IOC para realizar la inyección en los objetos DAO. 

Spring proporciona su propia jerarquía de excepción, que se encuentra en las jerarquías de excepción de las herramientas de mapeo  que soporta. Se detecta cualquier excepción o error de base de datos que podrían ser lanzados a través de JDBC, o la herramienta de mapeo subyacente, y traduce la excepción detectada a una excepción correspondiente en su propia jerarquía. 

Nota: La jerarquía excepción se define como una subclase de org.springframework.dao.DataAccessException. Spring detecta cualquier excepción lanzada de persistencia subyacente y lo envuelve en una instancia DataAccessException. 

Spring proporciona distintas clases DAO de base para las diferentes tecnologías de acceso a datos que soporta. 

Por ejemplo, Spring ofrece HibernateDaoSupport de Hibernate, SqlMapClientDaoSupport para iBATIS JdoDaoSupport para JDO y SQL Maps. Estas clases envuelven las propiedades y métodos que se requieren en DAO comunes.

Cuando se utiliza Hibernate con Spring, las clases DAO que utilizaremos es  org.springframework.orm.hibernate3.support.HibernateDaoSupport. Esta clase envuelve una instancia de org.springframework.orm.hibernate3.HibernateTemplate, que a su vez envuelve una instancia org.hibernate.SessionFactory. Extendiendo la clase HibernateDaoSupport permite configurar todas las implementaciones DAO como Bean en el interior del contenedor IoC. Su propiedad SessionFactory se configura  a través de un contexto de Spring.

package com.packtpub.springhibernate.ch13;

import java.util.Collection;

public interface StudentDao {
 public Student getStudent(long id);
 public Collection getAllStudents();
 public Collection getGraduatedStudents();
 public Collection findStudents(String lastName);
 public void saveStudent(Student std);
 public void removeStudent(Student std);
}

Nota: HibernateException es lanzada por el incumplimiento al interactuar directamente con Hibernate. Cuando se utiliza Spring, HibernateException se tradujo a DataAccessException por cualquier falla persistencia. Ambas excepciones son sin control, por lo que no es necesario para su captura si no quieres hacerse.

Ahora veremos nuestro código utilizando Spring, heredando de la clase HibernateDaoSupport y implementando mi interfaz antes mencionada.

package com.packtpub.springhibernate.ch13;

import org.springframework.orm.hibernate3.support.HibernateDaoSupport;

import java.util.Collection;

public class HibernateStudentDao extends HibernateDaoSupport implements StudentDao 
{

 public Student getStudent(long id) {
     return (Student) getHibernateTemplate().get(Student.class, new Long(id));
 }

 public Collection getAllStudents(){
     return getHibernateTemplate().find("from Student std order by std.lastName, std.firstName");
 }

 public Collection getGraduatedStudents(){
     return getHibernateTemplate().find("from Student std where std.status=1");
 }

 public Collection findStudents(String lastName) {
     return getHibernateTemplate().find("from Student std where std.lastName like ?", lastName + "%");
 }

 public void saveStudent(Student std) {
     getHibernateTemplate().saveOrUpdate(std);
 }

 public void removeStudent(Student std) {
     getHibernateTemplate().delete(std);
 }
}

Que les puedo decir que escucharía la música de ricardo montaner, "soy feliz, soy feliz lalalala" por que redujo mi código  me quito responsabilidades para brindarle al propio framework Spring!!!.

 Las operaciones persistentes implementadas por la clase DAO Como se puede ver , todos los métodos persistentes de la clase DAO utiliza el getHibernateTemplate () para acceder al objeto HibernateTemplate.  HibernateTemplate es una clase de Spring que se encarga de  trabajar con Hibernate . Esta clase expone todos los métodos Session de Hibernate , así como una variedad de otros métodos convenientes que las clases DAO pueden necesitar. 

 Debido HibernateTemplate tiene metodos que no están expuestos por la interfaz Session , puede utilizar find () y findByCriteria () cuando se desea ejecutar HQL o crear un objeto Criteria. Además, se envuelve todas las excepciones subyacentes lanzadas por el método sesión con instancias del org.springframework.dao.DataAccessException.

Es recomendable siempre usar la clase HibernateDaoSupport como clase base para todas las implementaciones de Hibernate DAO , pero se puede pasar por alto esta clase y trabajar directamente con una instancia HibernateTemplate en las clases DAO . Para ello , defina una propiedad de HibernateTemplate en la clase DAO , que se inicializa y configura a través del contenedor IoC de Spring.
El siguiente código muestra la clase DAO , que ahora utiliza HibernateTemplate directamente . Tenga en cuenta que no se recomienda este método porque hace que te involucres con el objeto HibernateTemplate tanto en la clase DAO como en el contenedor IOC de Spring.

 
package com.packtpub.springhibernate.ch13;

import org.springframework.orm.hibernate3.HibernateTemplate;

import java.util.Collection;

public class HibernateStudentDao implements StudentDao {

HibernateTemplate hibernateTemplate;

 public Student getStudent(long id) {
  return (Student) getHibernateTemplate().get(Student.class, new Long(id));
 }

 public Collection getAllStudents(){
  return getHibernateTemplate().find("from Student std order by std.lastName, std.firstName");
 }

 public Collection getGraduatedStudents(){
  return getHibernateTemplate().find("from Student std where std.status=1");
 }

 public Collection findStudents(String lastName) {
  return getHibernateTemplate().find("from Student std where std.lastName like "+ lastName + "%");
 }

 public void saveStudent(Student std) {
  getHibernateTemplate().saveOrUpdate(std);
 }

 public void removeStudent(Student std) {
  getHibernateTemplate().delete(std);
 }

 public HibernateTemplate getHibernateTemplate() {
  return hibernateTemplate;
 }

 public void setHibernateTemplate(HibernateTemplate hibernateTemplate) {
  this.hibernateTemplate = hibernateTemplate;
 }
}

Nota: Podemos observar una propiedad de la clase que recibe claramente el Hibernatetemplate por setter lo que hace pensar que lógicamente realizaremos una inyección de este objeto desde el spring bean configuration o contenedor de beans.

Configurando Hibernate en un Spring Context

 Spring proporciona la clase LocalSessionFactoryBean como una fábrica para un objeto SessionFactory. El objeto LocalSessionFactoryBean se configura como un Bean en el interior del contenedor IoC, ya sea como un  JDBC DataSource local o un Datasource compartido por JNDI.

 Definiendo el datasource local para MYSQL

 
<bean id="dataSource" 
class="org.apache.commons.dbcp.BasicDataSource">
<property name="driverClassName">
<value>com.mysql.jdbc.Driver</value>
</property>
<property name="url">
<value>jdbc:mysql://localhost:3306/gestioncursos</value>
</property>
<property name="username">
<value>root</value>
</property>
<property name="password">
<value></value>
</property>
</bean>

El siguiente punto es como definir la LocalSessionFactoryBean, para esto utiliza 3 propiedades datasource, mappingResources, y hibernateProperties.

 Datasource: La forma de conexión con nuestro motor de base de datos.
MappingResources: Hace referencia a los archivo HBM de mapeo Hibernate.
HibernateProperties: Configuración de hibernate que antes estaba en el archivo de configuracion propio de hibernate y que lo podremos realizar desde aquí.

 
<bean id="sessionFactory"
class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
<property name="dataSource">
<ref bean="dataSource"/>
</property>
<property name="mappingResources">
<list>
<value>com/packtpub/springhibernate/ch13/Student.hbm.xml</value>
<value>com/packtpub/springhibernate/ch13/Teacher.hbm.xml</value>
<value>com/packtpub/springhibernate/ch13/Course.hbm.xml</value>
</list>
</property>
<property name="hibernateProperties">
<props>
<prop key="hibernate.dialect">org.hibernate.dialect.HSQLDialect
</prop>
<prop key="hibernate.show_sql">true</prop>
<prop key="hibernate.max_fetch_depth">2</prop>
</props>
</property>
</bean>

Otra posibilidad es la definir nuestro LocalSessionFactoryBean con el viejo archivo de configuracion de hibernate hibernate.cfg.xml, para lo que lo definimos de la siguiente manera.

 
<bean id="sessionFactory"
class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
<property name="dataSource">
<ref bean="dataSource"/>
</property>
<property name="configLocation">
<value>/conf/hibernate.cfg.xml</value>
</property>
</bean>

Nota: como podemos observar le indicamos al bean donde se encuentra el archivo de configuración hibernate. Esta es una opción valida para el que quiere seguir manejando la configuración hibernate centralizada en el propio archivo de configuración.

Los que nos queda ahora es definir el bean que hace referencia a nuestro Dao a quien lógicamente le inyectaremos por medio de IOC el SessionFactory para que nuestro dao disponga de la conexion.

 
<bean id="studentDao" 
class="com.packtpub.springhibernate.ch13.HibernateStudentDao">
<property name="sessionFactory">
<ref local="sessionFactory"/>
</property>
</bean>

Nota: Esta es la configuración DAO para una clase DAO que se extiende HibernateDaoSupport, o utiliza una propiedad SessionFactory directamente.

 Cuando la clase DAO tiene una propiedad HibernateTemplate, configurar la instancia DAO de la siguiente manera:

 
<bean id="studentDao" 
class="com.packtpub.springhibernate.ch13.HibernateStudentDao">
<property name="hibernateTemplate">
<bean 
class="org.springframework.orm.hibernate3.HibernateTemplate">
<constructor-arg>
<ref local="sessionFactory"/>
</constructor-arg>
</bean>
</property>
</bean>

si recordamos para este caso hay una propiedad set para la hibernatetemplate por lo que en primera instancia inyectamos la hibernatetemplate por setter, y a la misma le inyectamos la sessionfactory.

 Administrando las transacciones con Spring.

 Si bien es un tema que ya abordamos de manera individual en anteriores entregas creo que vamos a dedicarle un momento por que estamos hablando de un escenario de integración donde por supuesto no le brindaremos el detalle que ya dedicamos en la entrada de este tema.

 Una de las razones para integrar Hibernate con Spring es la gestión de transacciones. Spring proporciona una capa de abstraccion de transacción sobre la API Transaction de Hibernate, y permite operaciones persistentes para participar en las operaciones globales. 

 Por otra parte, Spring ofrece demarcación de transacciones declarativa, que produce más legible y fácil de mantener el código de Java. El enfoque declarativo nos permite cambiar la estrategia de operación con facilidad, sin necesidad de cambiar el código por medio de la utilización de AOP.

 Spring Transaction proporciona 2 clases para trabajar con aplicaciones Hibernate:
  • org.springframework.transaction.support.TransactionTemplate para manejarlo por programación.
  • org.springframework.transaction.interceptor.TransactionProxyFactoryBean para manejarlo de manera declarativa.

dicho esto por otro lado proporciona dos administradores de transacciones:
  • org.springframework.orm.hibernate3.HibernateTransactionManager: Es necesario utilizar esta opción cuando la aplicación incluye una fuente de datos única solo para hibernate. Esto cubre las transacciones locales ejecutados en un solo SessionFactory. Este gestor se usa comúnmente, ya que la mayoría de las aplicaciones de Hibernate trabajan con una sola base de datos.
  • org.springframework.transaction.jta.JtaTransactionManager: Este es administrador de transacciones JTA global de Spring. Úsalo cuando la aplicación participa en las operaciones globales en un entorno Java EE, en la que están implicados varios métodos SessionFactory, y las transacciones se encuentran dispersos sobre ellos.
Nota: Configure las transacciones de Spring por la creación de la instancia de transacción-manager como un Bean en el interior del contenedor IoC. La configuración de Bean depende de la estrategia de operación que esté utilizando: local o global.

Configurando transacciones locales: cuando utilicemos una única fuente de datos utilizaremos esta configuración.

<bean id="transactionManager"
class="org.springframework.orm.hibernate3.
HibernateTransactionManager">
<property name="sessionFactory">
<ref bean="sessionFactory"/>
</property>
</bean>

ahora subamos el nivel utilizando un poco de AOP

 Finalmente , los casos DAO se envuelven en una transacción de proxy . Las transacciones son temas transversales que no se dedican a la función de un método en particular. En cambio, están dispersos en muchos métodos de persistencia . Con la primavera , funcionalidad DAO se puede dividir en dos módulos :

 Implementaciones de DAO , que realizan operaciones de persistencia .
Asesoramiento de transacciones , que define cómo se realizan las operaciones de persistencia en las transacciones.

 Modularización implementaciones DAO para llevar a cabo las operaciones de persistencia y no de gestión de transacciones, evita código de gestión de transacciones repetitivo en todos los métodos de persistencia. Para solicitar asesoramiento de transacciones con los métodos de destino de las implementaciones de DAO , necesitamos objetos proxy .

 Cada proxy es un objeto que intermedios entre otros dos objetos (un objeto que llama y un objeto invocado ) , y se aplica ( una transacción en nuestro caso ) a la invocación objeto. En realidad , la capa de negocio siempre trabaja con instancias de proxy en lugar de objetos de servicio. He aquí un ejemplo de la definición de proxy transacción :

<bean 
id="studentDao" class="org.springframework.transaction.
interceptor.TransactionProxyFactoryBean">
<property name="transactionManager">
<ref bean="transactionManager"/>
</property>
<property name="target">
<ref bean="persistenceService"/>
</property>
<property name="transactionAttributes">
<props>
<prop key="save*">PROPAGATION_REQUIRED</prop>
<prop key="*">PROPAGATION_REQUIRED,readOnly</prop>
</props>
</property>
</bean>

El objeto TransactionProxyFactoryBean está configurado con tres propiedades:
TransactionManager, declarado como un grano individual, es un objeto que proporciona una API de abstracción entre el código de la aplicación y Hibernate API transacción.

 Target representa el objeto al que la transacción debe ser aplicado.

 transactionAttributes define la forma de seleccionar los métodos transaccionales. Por ejemplo, guardar * selecciona todos los métodos del objeto de destino que se inician con la palabra guardar.

 En nuestro ejemplo, PROPAGATION_REQUIRED y readOnly especifican, respectivamente, cómo participan múltiples transacciones, y si la transacción se permite sólo leer los datos.

Nota Final: En lo personal les diría que miren la documentación de Spring sobre estos temas por que solo abordamos algunas de la posibilidades que te brinda el framework y de seguro puede cubrir sus necesidades y estoy convencido que puede mejorar tu forma de programar.

El código del proyecto lo puede descargar en codigofuente.zip.

 Entendiendo la estructura de mi proyecto.
Podemos observar la estructura del proyecto. 

 El codigo proporciona los 3 casos abordados.

  • El manejo de hibernate tradicional 
  • El manejo de spring + Hibernate con hibernatedaosupport .
  • El manejo de spring + Hibernate con hibernatetemplate 
Es claro que hay paquetes son comunes para todos los ejemplos.


 En prima instancia el paquete hbm contiene los archivos de mapeo hibernate es un punto comun para los tres casos que abordamos en el tutorial.

 La siguiente carpeta en común es com.company.modelo que contiene el pojo que desde luego utilizaran todos los ejemplos.



SoloHibernate: Es el ejemplo que muestra la manera tradicional de trabajar con hibernate y tiene los siguientes paquetes.

  • com.company.solohibernate.dao: contiene la interfaz y la clase de implementacion.
  • com.company.solohibernate.service: contiene la interfaz y la clase de implementacion.
  • com.company.solohibernate.test: contiene la clase test desde donde realizamos pruebas al modelo creado.

Nota: Desde luego cuenta con el archivo de configuración para Hibernate en la caerpeta resource y se llama hibernate.cfg.xml

 HibernateDaoSupport: Es el ejemplo donde la clase dao extiene de hibernatedaosupport y tiene los siguiente paquetes.

  • com.company.springhibernate.hibernatedaosupport.dao: contiene la interfaz y la clase de implementacion.
  • com.company.springhibernate.hibernatedaosupport.service: contiene la interfaz y la clase de implementacion.
  • com.company.springhibernate.hibernatedaosupport.test: contiene la clase test desde donde realizamos pruebas al modelo creado.

Nota: Desde luego cuenta con el archivo de configuración Spring bean configuration llamado hibernatedaosupport.xml.

HibernateTemplate: Es el ejemplo donde la clase dao hace uso de manera directa de HibernateTemplate.

  • com.company.springhibernate.dao: contiene la interfaz y la clase de implementacion.
  • com.company.springhibernate.service: contiene la interfaz y la clase de implementacion.
  • com.company.springhibernate.test: contiene la clase test desde donde realizamos pruebas al modelo creado.

Nota: Desde luego cuenta con el archivo de configuración Spring bean configuration llamado hibernatetemplate.xml.

Nota Final: La gestión de transacciones lo deje fuera del ejemplo por una cuestión de tiempo y  que es un tema abordado ya en una anterior entrega con mayor detalle y por que creo que con este tutorial podrán incluir la gestión de transacciones sin problema.

Pero en lo personal recomiendo este libro de referencia para abordar el trabajo de Hibernate con Spring. El libro lo podemos descargar desde aqui. Libro.PDF
Publicado por en
Etiquetas:

No hay comentarios:

Publicar un comentario

Suscribirse a: Enviar comentarios (Atom)