Las relaciones uno a muchos (@OneToMany) se caracterizan por Entidad donde tenemos un objeto principal y colección de objetos de otra Entidad relacionados directamente. Estas relaciones se definen mediante colecciones, pues tendremos una serie de objetos pertenecientes al objeto principal.

Este articulo es parte de un guia completa de JPA, para ver el contenido completo puedes ir a Java Persistence API (JPA)

Un ejemplo clásico para entender este tipo de relaciones son las facturas, pues tendremos una Entidad cabecera donde tengamos los datos principales de la factura, como podría ser serie, cliente, total, fecha de expedición, etc. Por otra parte, la factura tendrá una serie de líneas que representa cada uno de los productos vendidos. 

Veamos como quedaría la entidad Invoice (factura):

package com.obb.jpa.jpaturorial.entity;

import java.util.Calendar;
import java.util.List;
import javax.persistence.*;

@Entity
@Table(name="INVOICES")
public class Invoice {
    
    @Id
    @Column(name="ID")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private long id;
    
    @Column(name = "STATUS", length = 20, nullable = false)
    @Enumerated(EnumType.STRING)
    private Status status;
    
    @Temporal(TemporalType.TIMESTAMP)
    @Column(name = "REGIST_DATE", nullable = false)
    private Calendar registDate;
    
    @JoinColumn(name = "FK_CUSTOMER", nullable = false)
    @ManyToOne(optional = false, cascade = CascadeType.ALL, fetch = FetchType.EAGER)
    private Customer customer;
    
    @OneToOne(mappedBy = "invoice", cascade = CascadeType.ALL)
    private Payment payment;
    
    @OneToMany(cascade = CascadeType.ALL, mappedBy = "invoice")
    private List<InvoiceLine> lines;

    /** GET and SET */
}

Podemos apreciar como hemos definido la propiedad lines como una lista (List), lo cual nos permite relacionar la factura con un número indeterminado de líneas, por otro lado, hemos definido la propiedad mappedBy para indicar que es una relación bidireccional, es decir, la Entidad InvoiceLine tendrá también una relación hacia la Entidad Invoice.

La Entidad InvoiceLine se verá de la siguiente manera:

package com.obb.jpa.jpaturorial.entity;

import javax.persistence.*;

@Entity
@Table(name = "invoice_lines")
public class InvoiceLine {
    @Id
    @Column(name = "ID")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    @Column(name = "PRODUCT", nullable = false)
    private String product;
    
    @Column(name = "PRICE", nullable = false)
    private double price;
    
    @Column(name = "TOTAL", nullable = false)
    private double quantity;
    
    @ManyToOne
    @JoinColumn(name = "FK_INVOICE", nullable = false, updatable = false)
    private Invoice invoice;
    
    /** GET and SET */

}

Como dijimos hace un momento, la Entidad InvoiceLine tiene una propiedad de tipo Invoice para poderla hacer bidireccional, observemos que el nombre de la propiedad invoice corresponde con el valor del mappedBy definido en la Entidad Invoice, ya que de lo contrario JPA nos arrojará un error.

Tambíen los quiero invitar a ver mi curso de JPA, donde explico todos estos temas aplicados con API REST, https://codmind.com/courses/jpa

En este imagen podemos apreciar que la tabla invoice_lines tiene la columna FK_INVOICE que será utilizada para realizar el JOIN con la tabla invoices, de tal forma que cada registro de invoice_lines que sea encontrado será convertido en una instancia de la Entidad InvoiceLine.

public static void main(String[] args) {
    Invoice invoice = new Invoice();

    List<InvoiceLine> lines = new ArrayList<>();
    for(int c = 0; c<10; c++){
        InvoiceLine line = new InvoiceLine();
        line.setInvoice(invoice);
        line.setPrice(10);
        line.setProduct("Product " + (c+1));
        line.setQuantity(c+1);
        lines.add(line);
    }

    Customer customer = new Customer();
    customer.setName("Oscar Blancarte");

    invoice.setCustomer(customer);
    invoice.setLines(lines);
    invoice.setRegistDate(Calendar.getInstance());
    invoice.setStatus(Status.ACTIVE);

    EntityManager em = EntityManagerUtil.getEntityManager();
    em.getTransaction().begin();
    em.persist(invoice);
    em.getTransaction().commit();
}

Dando como resultado los siguientes registros en la base de datos:

Ahora si podemos ver todo materializado y nos queda más la forma en que la información es almacenada. 

Conclusiones

Hemos comprobado lo simple que es crear relaciones @OneToMany y hemos podido comprobar como  la información es almacenada, solo faltaría resaltar que JPA no garantiza el orden en que los elementos de la colección son insertados, es por ello, que siempre se aconseja tener una columna que indique el orden natural de los elementos para sobre esa columna hacer el ordenamiento, esto claro si nos interesa mantener el ordenamiento, en caso podemos ignorarlo.

Las relaciones One to One (@OneToOne) se caracterizan porque solo puede existir una y solo una relación con la Entidad de destino, de esta forma, la entidad marcada como @OnoToOne deberá tener una referencia a la Entidad destino y por ningún motivo podrá ser una colección. De la misma forma, la Entidad destino no podrá pertenecer a otra Instancia de la Entidad origen.

Solo para ponernos en contexto, las relaciones @OneToOne se utilizan cuando existe una profunda relación entre la Entidad origen y destino,de tal forma que la entidad destino le pertenece a la Entidad origen y solo a ella, por ende, la existencia de la entidad destino depende de la Entidad origen.

Para comprender mejor todo este trabalenguas, analicemos el caso práctico de una factura, cuando creamos una factura, la llevamos con nuestro cliente para que la pague, este pago puede ser una entidad por separada que lleve el control de la fecha de pago, monto pagado, método de pago, etc. Veamos como quedarían esta Entidades

Entidad Invoice:

package com.obb.jpa.jpaturorial.entity;

import java.util.Calendar;
import javax.persistence.*;

@Entity
@Table(name="INVOICES")
public class Invoice {
    
    @Id
    @Column(name="ID")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private long id;
    
    @Column(name = "STATUS", length = 20, nullable = false)
    @Enumerated(EnumType.STRING)
    private Status status;
    
    @Temporal(TemporalType.TIMESTAMP)
    @Column(name = "REGIST_DATE", nullable = false)
    private Calendar registDate;
    
    @JoinColumn(name = "FK_CUSTOMER", nullable = false)
    @ManyToOne(optional = false, cascade = CascadeType.ALL, fetch = FetchType.EAGER)
    private Customer customer;
    
    @OneToOne(mappedBy = "invoice", cascade = CascadeType.ALL)
    private Payment payment;

    /** GET and SET */
    
}

Entidad Payment:

package com.obb.jpa.jpaturorial.entity;

import java.util.Calendar;
import javax.persistence.*;

/**
 * @author Oscar Blancarte <oscarblancarte3@gmail.com>
 */
@Entity
@Table(name = "payments")
public class Payment {
    
    @Id
    @Column(name = "ID")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    @Temporal(TemporalType.TIMESTAMP)
    @Column(name="PAY_DATE", nullable = false, updatable = false)
    private Calendar payDate;
    
    @Column(name = "AMOUNT", nullable = false, updatable = false)
    private double amount;
    
    @Column(name = "PAY_METHOD", nullable = false, updatable = false)
    private PaymentMethod paymentMethod;
    
    @OneToOne
    @JoinColumn(name = "FK_INVOICE", updatable = false, nullable = false)
    private Invoice invoice;

    /** GET and SET */
}

Estas dos Entidades crearán las siguientes tablas:

Como podemos observar, la tabla payments tiene la columna FK_INVOICE que hace relación con la tabla invoices.

Tambíen los quiero invitar a ver mi curso de JPA, donde explico todos estos temas aplicados con API REST, https://codmind.com/courses/jpa

Algo que hay que tomar en cuenta, es que tanto la Entidad Invoice como Payment tiene anotada como @OneToOne a la otra entidad, sin embargo, solo payments ha creado la columna para hacer el JOIN, esto se debe a que esta es la que tiene la anotación @JoinColumn, la cual nos permite establecer como se llamará la columna para realizar el JOIN, adicional, la Entidad Invoice tiene definida la propiedad mappedBy de la anotación @OneToOne, esta propiedad es muy importante, pues le permite hacer una relación bidireccional, si no la pusiéramos, JPA agregaría una columna adicional en la tabla invoices, y guardaría el pago como un nuevo registro.

Veamos un ejemplo de cómo se crearía un registro con esta relación:

public static void main(String[] args) {
        EntityManager manager = EntityManagerUtil.getEntityManager();
        
        Customer customer = new Customer();
        customer.setName("Oscar Blancarte");
        
        Payment payment = new Payment();
        payment.setAmount(100);
        payment.setPayDate(Calendar.getInstance());
        payment.setPaymentMethod(PaymentMethod.CASH);
                
        
        Invoice invoice = new Invoice();
        invoice.setCustomer(customer);
        invoice.setRegistDate(Calendar.getInstance());
        invoice.setStatus(Status.ACTIVE);
        
        payment.setInvoice(invoice);
        invoice.setPayment(payment);
        
        manager.getTransaction().begin();
        manager.persist(invoice);
        manager.getTransaction().commit();
    }

Dando como resultado lo siguiente:

Conclusiones

Crear relaciones OneToOne es muy simple como hemos podido comprobar, e incluso, podríamos crear una relación unidireccionar omitiendo la propiedad payment de la entidad Invoice, lo que diera como resultado exactamente la misma estructura de base de datos, con la única limitante que no podríamos recuperar el pago por medio de la factura y es por ello que utilizamos relacionar bidireccionales con mappedBy.

Nota: Este artículo pertenece a un tutorial completo de JPA, el cual puedes ver aquí.

La anotación @JoinColumn  se puede llegar a confundir con @Column , sin embargo, tiene una funcionalidad diferente, @JoinColumn  se utiliza para marcar una propiedad la cual requiere de un JOIN para poder accederlas, mientas que @Column  se utiliza para representar columnas simples que no están relacionadas con otra Entidad. A pesar de que se utiliza para cosas distintas, la realidad es que se parecen muchísimo, pues tiene casi las mismas propiedades, por que podríamos decir que @JoinColumn  es el equivalente de @Column  cuando utilizamos relaciones con Entidades.

En la entrada pasada de este tutorial explicamos el caso de la Entidad Factura (Invoice ) y Cliente (Customer ), donde dijimos que toda factura está relacionada a un cliente, y utilizamos la anotación @ManyToOne  para crear la relación, recordemos como quedaron estas Entidades:

package com.obb.jpa.jpaturorial.entity;
 
import java.util.Calendar;
import javax.persistence.CascadeType;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.EnumType;
import javax.persistence.Enumerated;
import javax.persistence.FetchType;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.ManyToOne;
import javax.persistence.Table;
import javax.persistence.Temporal;
import javax.persistence.TemporalType;
 
@Entity
@Table(name="INVOICES")
public class Invoice {
    
    @Id
    @Column(name="ID")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private long id;
    
    @Column(name = "STATUS", length = 20, nullable = false)
    @Enumerated(EnumType.STRING)
    private Status status;
    
    @Temporal(TemporalType.TIMESTAMP)
    @Column(name = "REGIST_DATE", nullable = false)
    private Calendar registDate;
    
    @ManyToOne(optional = false, cascade = CascadeType.ALL, fetch = FetchType.EAGER)
    private Customer customer;
 
    /** GET and SET */
}

Entidad Customer:

package com.obb.jpa.jpaturorial.entity;
 
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Table;
 
@Entity
@Table(name = "CUSTOMERS")
public class Customer {
    
    @Id
    @Column(name = "ID")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private long id;
    
    @Column(name = "NAME", nullable = false, length = 100)
    private String name;
 
    /** GET and SET */
}

Podemos ver claramente que la Entidad Invoice  tiene una relación @ManyToOne  con la Entidad Customer , esto le indica a JPA que requerirá hacer un JOIN para poder recuperar al Cliente, sin embargo, no hemos definido la anotación @JoinColumn  y aun así trabaja, ¿cómo es esto posible?

Para comprender esto mejor, será necesario ver como JPA auto creo las tablas al momento de crear el schema, veamos las tablas generadas:

Podemos ver claramente que JPA creo la columna CUSTOMER_ID en la tabla invoices, pero no solo eso, si no que además, creo por nosotros la llave foránea, esto nos puede hacer pensar que la anotación @JoinColumn  no es necesaria, y pueda que tengas razón, sin embargo, no utilizarla nos dejará a merced de como JPA genere la columna y como realice el JOIN con la tabla de empleados, lo cual será un verdadero problema si el Schema ya existe, pues muy probablemente la consulta falle al buscar la columna con un nombre diferente del que JPA asumiría.

Ahora bien, con @JoinColumn , podría definir el nombre exacto de la columna, si admite nulos, si es actualizable, insertable, indicar si queremos que genere o no la llave foránea o incluso, podríamos decirle sobre que Tabla debe generar el Join. Mejor veamos como quedaría la Entidad Invoice  utilizando la anotación @JoinColumn :

package com.obb.jpa.jpaturorial.entity;
 
import java.util.Calendar;
import javax.persistence.CascadeType;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.EnumType;
import javax.persistence.Enumerated;
import javax.persistence.FetchType;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.ManyToOne;
import javax.persistence.Table;
import javax.persistence.Temporal;
import javax.persistence.TemporalType;
 
@Entity
@Table(name="INVOICES")
public class Invoice {
    
    @Id
    @Column(name="ID")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private long id;
    
    @Column(name = "STATUS", length = 20, nullable = false)
    @Enumerated(EnumType.STRING)
    private Status status;
    
    @Temporal(TemporalType.TIMESTAMP)
    @Column(name = "REGIST_DATE", nullable = false)
    private Calendar registDate;
    
    @JoinColumn(name = "fk_customer", nullable = false)
    @ManyToOne(optional = false, cascade = CascadeType.ALL, fetch = FetchType.EAGER)
    private Customer customer;
 
    /** GET and SET */
}

Ahora veamos como quedaría la nueva tabla invoices:

En esta segunda tabla ya vemos que ha cambiado el nombre de la columna, adicional se ha creado el constraint para no permitir valores nulos, aun que esto último no se pueda ver en la imagen.

Propiedades de @JoinColumn

Ahora pasemos a analizar las propiedades que nos brinda @JoinColumn :

• name: Indica el nombre con el que se deberá de crear la columna dentro de la tabla.
• referencedColumnName: Se utiliza para indicar sobre que columna se realizará el Join de la otra tabla. Por lo general no se suele utilizar, pues JPA asume que la columna es el ID de la Entidad objetivo.
• unique: Crea un constraints en la tabla para impedir valores duplicados (default false).
• nullable: Crea un constraints en la tabla para impedir valores nulos (default true).
• insertable: Le indica a JPA si este valor deberá guardarse en la operación de inserción (default true)
• updatable: Le indica a JPA si el valor deberá actualizarse durante el proceso de actualización (default true)
• columnDefinition: Esta propiedad es utiliza para indicar la instrucción SQL que se deberá utilizar la crear la columna en la base de datos. Esta nos ayuda a definir exactamente como se creará la columna sin depender de la configuración de JPA.
• table: Le indicamos sobre que tabla deberá realizar el JOIN, normalmente no es utilizada, pues JPA asume la tabla por medio de la entidad objetivo.
• foreignKey: Le indica a JPA si debe de crear el Foreign Key, esta propiedad recibe uno de los siguientes valores CONSTRAINT , NO_CONSTRAINT , PROVIDER_DEFAULT  definidos en la enumeración javax.persistence.ForeignKey .

Tambíen los quiero invitar a ver mi curso de JPA, donde explico todos estos temas aplicados con API REST, https://codmind.com/courses/jpa

Conclusiones

Hemos podido analizar como es que JPA se apoya de @JoinColumn  para permitirle al programador personalizar cada aspecto de la columna de unión, lo cual es bastante bueno para poder respetar los estándares o nomenclaturas que usamos en nuestra empresa o proyecto. Como recomendación, yo siempre insisto en definir estas anotaciones, pues no es conveniente quedarnos a merced de la implementación de JPA para que defina como crear nuestras columnas.

Para comprender esto, analicemos el ejemplo de las facturas, estas siempre son emitidas a un cliente, por lo que el objeto Factura siempre deberá tener una propiedad que represente al cliente. Normalmente, esta propiedad seria el ID, sin embargo, JPA nos permite tener una referencia a la Entidad cliente. Veamos cómo quedaría la Entidad Invoice  (factura)

package com.obb.jpa.jpaturorial.entity;

import java.util.Calendar;
import javax.persistence.CascadeType;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.EnumType;
import javax.persistence.Enumerated;
import javax.persistence.FetchType;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.ManyToOne;
import javax.persistence.Table;
import javax.persistence.Temporal;
import javax.persistence.TemporalType;

@Entity
@Table(name="INVOICES")
public class Invoice {
    
    @Id
    @Column(name="ID")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private long id;
    
    @Column(name = "STATUS", length = 20, nullable = false)
    @Enumerated(EnumType.STRING)
    private Status status;
    
    @Temporal(TemporalType.TIMESTAMP)
    @Column(name = "REGIST_DATE", nullable = false)
    private Calendar registDate;
    
    @ManyToOne(optional = false, cascade = CascadeType.ALL, fetch = FetchType.EAGER)
    private Customer customer;

    /** GET and SET */
}

Como podemos apreciar, hemos utiliza la anotación @ManyToOne , la cual nos permite mapear una entidad con otra. Como única regla, es necesario la clase que sea una entidad, es decir, que también esté anotada con @Entity .

Por otro lado, tenemos la entidad Customer , la cual se ve de la siguiente manera:

package com.obb.jpa.jpaturorial.entity;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Table;

@Entity
@Table(name = "CUSTOMERS")
public class Customer {
    
    @Id
    @Column(name = "ID")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private long id;
    
    @Column(name = "NAME", nullable = false, length = 100)
    private String name;

    /** GET and SET */
}

Estas dos entidades nos crearán las siguientes tablas:

La anotación @ManyToOne cuenta con los siguientes atributos:

• Optional: indica si la relación es opcional, es decir, si el objeto puede ser null. Esta propiedad se utiliza optimizar las consultas. Si JPA sabe que una relación es opcional, entonces puede realizar un RIGHT JOIN  o realizar la consulta por separado, mientras que, si no es opcional, puede realizar un INNER JOIN  para realizar una solo consulta.
• Cascade: Esta propiedad le indica que operaciones en cascada puede realizar con la Entidad relacionada, los valores posibles son ALL , PERSIST , MERGE , REMOVE , REFRESH , DETACH y están definidos en la enumeración javax.persistence.CascadeType .
• Fetch: Esta propiedad se utiliza para determinar cómo debe ser cargada la entidad, los valores están definidos en la enumeración javax.persistence.FetchType  y los valores posibles son:
  • EAGER (ansioso): Indica que la relación debe de ser cargada al momento de cargar la entidad.
  • LAZY (perezoso): Indica que la relación solo se cargará cuando la propiedad sea leída por primera vez.
• targetEntity: Esta propiedad recibe una clase (Class ) la cual corresponde a la clase de la relación. No suele ser utilizada, pues JPA puede inferir la clase por el tipo de la propiedad.

En nuestro caso, hemos definido la propiedad optional en false, pues toda factura debe de tener forzosamente un Cliente (customer). La propiedad cascade la definimos en ALL  para facilitarnos la explicación de este ejemplo, pero más adelante en este tutorial analizaremos las cascadas en profundidad. La propiedad fetch la definimos en EAGER , aun que para este tipo de relación es su valor por default y no sería necesario definirlo.

Ejemplo práctico

Crearemos un pequeño ejemplo que nos permita comprobar cómo trabajar con esta relación, para ello, crearemos una nueva factura con un cliente:

public static void main(String[] args) {
    EntityManager manager = EntityManagerUtil.getEntityManager();
        
    Customer customer = new Customer();
    customer.setName("ACME Corp");
      
    Invoice invoice = new Invoice();
    invoice.setCustomer(customer);
    invoice.setRegistDate(Calendar.getInstance());
    invoice.setStatus(Status.ACTIVE);
        
    manager.getTransaction().begin();
    manager.persist(invoice);
    manager.getTransaction().commit();
}

Como resultado, podemos observar como han sido insertados la Factura y el Cliente:

Por otra parte, si consultamos la Entidad Invoice, JPA se encargará de cargar al Empleado, vamos el siguiente ejemplo:

public static void main(String[] args) {
    EntityManager manager = EntityManagerUtil.getEntityManager();
    Invoice invoice = manager.find(Invoice.class, 1L);
        
    System.out.println("Invoice ID > " + invoice.getId());
    System.out.println("Customer ID > " + invoice.getCustomer().getId());
    System.out.println("Customer Name > " + invoice.getCustomer().getName());
}

Como podemos apreciar en la siguiente imagen, no fue necesario ir a consultar el Cliente por separado, si no que JPA se encarga de recuperarlo justo en el momento en que lo necesitamos.

Finalmente, podemos ver en las siguiente imágenes como es que nos auto genero la tabla de las facturas, en ella podemos apreciar el campo CUSTOMER_ID , el cual es en realidad una llave foránea a la tabla de clientes:

JPA también nos ayuda a crear los Foreign Keys con la tabla de Clientes:

Tambíen los quiero invitar a ver mi curso de JPA, donde explico todos estos temas aplicados con API REST, https://codmind.com/courses/jpa

Conclusiones

Hemos podido observar como JPA se encarga de todo lo relacionado a persistir o recuperar el cliente de la base de datos, sin embargo, hay algo que no hemos cubierto, y es la forma en que podemos personalizar la columna, es decir, como podemos indicarle el nombre, si admite nulos o no, etc. Todas esta propiedades las podremos definir en la anotación @JoinColumn  que analizaremos en la siguiente parte del tutorial

Es ejemplo lo realizo con la Base de datos Oracle 11g XE y con la versión de Hibernate 4.3.

Codigo del Store Procedure.

A continuación el código con la explicación:

package com.oscarblancarte.hibernate;

import java.util.concurrent.Executors;
import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.TimeUnit;

import javax.persistence.ParameterMode;

import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.boot.registry.StandardServiceRegistryBuilder;
import org.hibernate.cfg.Configuration;
import org.hibernate.procedure.ProcedureCall;
import org.hibernate.service.ServiceRegistry;

public class HibernateProcedure {

	private static final SessionFactory sessionFactory = buildSessionFactory();

	public static void main(String[] args) {
		// Obtenemos la session
		Session session = getSessionFactory().getCurrentSession();

		// Abrimos transacción <OPCIONAL>
		session.beginTransaction();

		// Nombre del SP
		ProcedureCall call = session.createStoredProcedureCall("PROC1");
		// Registramos el primer parametros de entrada
		call.registerParameter(1, String.class, ParameterMode.IN);
		// Registramos el segundo parametro de salida
		call.registerParameter(2, Integer.class, ParameterMode.OUT);

		//Establecemos el valor del primer parametros de entrada
		call.getParameterRegistration(1).bindValue("hola");
		//Ejecutamos el SP y obtenemos el parametro 2, el cual es de salida(out)
		Object salida = call.getOutputs().getOutputParameterValue(2);
		//Se imprime el parametro de salida
		System.out.println("SALIDA ==> " + salida.toString());

		// cerramos transacción <OPCIONAL>
		session.getTransaction().commit();
		System.out.println("FIN");
	}

	private static SessionFactory buildSessionFactory() {
		try {
			Configuration configuration = new Configuration();
			configuration.configure("hibernate.cfg.xml");
			ServiceRegistry serviceRegistry = new StandardServiceRegistryBuilder()
					.applySettings(configuration.getProperties()).build();
			SessionFactory sessionFactory = configuration
					.buildSessionFactory(serviceRegistry);
			return sessionFactory;
		} catch (Throwable ex) {
			System.err.println("Initial SessionFactory creation failed." + ex);
			throw new ExceptionInInitializerError(ex);
		}
	}

	public static SessionFactory getSessionFactory() {
		return sessionFactory;
	}
}

La clave es registrar adecuadamente los parámetros, registrando su tipo de dato y Mode el cual puede ser de entrada o salida.

Por otro lado tenemos a JDBC que nos brinda total libertad de hacer lo que queramos sin ningún tipo de limitación explotando al máximo las características de la base datos. JDBC nos permite realizar consultas nativas para cada base de datos lo que ayuda mucho a la velocidad de respuesta y los resultados son devueltos en un ResultSet los cuales podemos extraer solamente los datos que requerimos y no toda la Entity como en el caso de JPA o Hibernate.

JPA,Hibernate

Ventajas

1. Nos permite desarrollar mucho mas rápido.
2. Permite trabajar con la base de datos por medio de entidades en vez de Querys.
3. Nos ofrece un paradigma 100% orientado a objetos.
4. Elimina errores en tiempo de ejecución.
5. Mejora el mantenimiento del software.

Desventajas

1. No ofrece toda la funcionalidad que ofrecería tirar consultas nativas.
2. El performance es mucho mas bajo que realizar las consultas por JBDC.
3. Puede representar una curva de aprendizaje mas grande.

JDBC

Ventajas

• Ofrece un performance superior ya que es la forma mas directa de mandar instrucciones la base de datos.
• Permite explotar al máximo las funcionalidades de la base de datos.

Desventajas

• El mantenimiento es mucho mas costoso.
• Introduce muchos errores en tiempo de ejecución.
• El desarrollo es mucho mas lento.

Probablemente pensaras que JPA o Hibernate son mejores ya que ofrece mayor ventajas que desventajas sin embargo las desventajas que tiene son muy serias y pueden ser cruciales a la hora de decidir que tecnología utilizar ya que si tenemos una aplicación muy buena y fácil de mantener pero que tarda demasiado para consultar datos puede llegar a ser algo muy malo.

Como conclusión yo diría que si requieres una aplicación donde el rendimiento sea el factor mas importante utilices JDBC, pero por otra parte si el rendimiento es algo que no están importante puedes utilizar JPA o Hibernate.

Tutorial de JPA Gratis!!

Si estás leyendo esto en este momento es por seguramente estas interesado en aprender Hibernate o JPA, pues te tengo buenas noticias, ya que he iniciado un tutorial muy completo de JPA para que aprendas desde cero y sin conocimientos previos como utilizar JPA. No te sientas mal si lo que tu buscas es aprender Hibernate, ya que actualmente existe una implementación de JPA desarrollada por Hibernate. Además, JPA es el ORM Estándar de Java y que se integra a la perfección con el resto de especificaciones de Java, como lo es EJB 3.X, CDI, Bean Validator, entre otras más. Pues bien, si estas interesado en tomar este tutorial puedes entrar aquí.