Las relaciones Mucho a Muchos (@ManyToMany) se caracterízan por Entidades que están relacionadas con a muchos elementos de un tipo determinado, pero al mismo tiempo, estos últimos registros no son exclusivos de un registro en particular, si no que pueden ser parte de varios, por lo tanto, tenemos una Entidad A, la cual puede estar relacionada como muchos registros de la Entidad B, pero al mismo tiempo, la Entidad B puede pertenecer a varias instancias de la Entidad A.

Algo muy importante a tomar en cuenta cuando trabajamos con relaciones @ManyToMany, es que en realidad este tipo de relaciones no existen físicamente en la base de datos, y en su lugar, es necesario crear una tabla intermedia que relaciones las dos Entidades, veremos más adelante como resolvemos eso.

Un ejemplo clásico de estas relaciones son los libros con sus autores, de esta forma, un libro puede tener varios autores, y a su vez, los autores puede tener muchos libros. Pero para que quede más claro, veamos como quedarían las Entidades de Autor (Author), Libro (Book):

Entidad Book:

package com.oscarblancarteblog;

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

@Entity
@Table(name = "books")
public class Book {
    @Id
    @Column(name="ID")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    @Column(name = "NAME", nullable = false)
    private String name;
    
    @JoinTable(
        name = "rel_books_auths",
        joinColumns = @JoinColumn(name = "FK_BOOK", nullable = false),
        inverseJoinColumns = @JoinColumn(name="FK_AUTHOR", nullable = false)
    )
    @ManyToMany(cascade = CascadeType.ALL)
    private List<Author> authors;
   
    public void addAuthor(Author author){
        if(this.authors == null){
            this.authors = new ArrayList<>();
        }
        
        this.authors.add(author);
    }

    /** GET and SET */
  
}

Como podemos apreciar, hemos creado una lista de tipo Author, la cual es anotada con @ManyToMany, adicional, hemos definido la anotación @JoinTable, la cual nos sirve para definir la estructura de la tabla intermedia que contendrá la relación entre los libros y los autores.

La anotación @JoinTable no es obligatoria en sí, ya que en caso de no definirse JPA asumirá el nombre de la tabla, columnas, longitud, etc. Para no quedar a merced de la implementación de JPA, siempre es recomendable definirla, así, tenemos el control total sobre ella.

Hemos definidos las siguientes propiedades de la anotación @JoinTable:

• name: Nombre de la tabla que será creada físicamente en la base de datos.
• joinColumns: Corresponde al nombre para el ID de la Entidad Book.
• inverseJoinColumns: Corresponde al nombre para el ID de la Entidad Author

Entidad Author:

package com.oscarblancarteblog;

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

@Entity
@Table(name="authors")
public class Author {
    
    @Id
    @Column(name="ID")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    @Column(name="NAME", nullable = false)
    private String name;
    
    @ManyToMany(mappedBy = "authors")
    private List<Book> books;

    /** GET and SET **/
}

El caso de la Entidad Author es más simple, pues solo marcamos la colección con @ManyToMany, pero en este caso ya no es necesario definir la anotación @JoinTable, en su lugar, definimos la propiedad mappedBy para indicar la relación bidireccional y al mismo tiempo, JPA puede tomar la configuración del @JoinTable de Books.

Como resultado de estas Entidades, tendremos las siguientes tablas auto generadas:

Notemos en la tabla authors no tiene una columna que haga referencia a books, ni books a authors, si no que es necesario tener una tabla intermedia que haga el cruce entre las dos tablas.

La tabla intermedia (rel_book_auths) es generada por la anotación @JoinTable y sus dos columnas son llaves foraneas a las tablas books y authors.

Prueba de validación

Para comprobar que todo funciona como lo hemos dicho, vamos a realizar una prueba, la cual se ve de la siguiente manera:

public static void main(String[] args) {
        
	//Authors
	Author author1 = new Author();
	author1.setName("Juan Perez");
	
	Author author2 = new Author();
	author2.setName("Oscar Blancarte");
	
	Author author3 = new Author();
	author3.setName("Arturo Martinez");
	
	
	//Books
	Book book1 = new Book();
	book1.setName("El lago y el pato");
	book1.addAuthor(author1);
	book1.addAuthor(author2);
	book1.addAuthor(author3);
	
	Book book2 = new Book();
	book2.setName("Una mañana de verano");
	book2.addAuthor(author1);
	book2.addAuthor(author2);
	book2.addAuthor(author3);
	
	EntityManager em = EntityManagerUtil.getEntityManager();
	em.getTransaction().begin();
	em.persist(book1);
	em.persist(book2);
	em.getTransaction().commit();
	
	System.out.println("FIN");
}

Hemos creados dos libros y tres autores, y luego hemos asociado a los autores a los libros, con la intención de que los autores estén en dos libros y los libros tengan varios autores.

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

Ahora veamos como se ven las tablas authors, books y rel_books_auths:

Para poder obtener la relación entre libros y autores solo faltaría hacer la unión entre las dos tablas.

Conclusiones

Para concluir solo faltaría resaltar que en las relaciones @ManyToMany los registros son independientes de los registros a los que son relacionados, por lo que en este caso, podrían existir los autores si no existieran los libros, y al revés.

The post Relaciónes @ManyToMany appeared first on Oscar Blancarte - Software Architecture.

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.

The post Relaciones @OneToMany appeared first on Oscar Blancarte - Software Architecture.

Por increíble que parezca, en REST la URL puede proporcionar una de las principales fuentes de información para los servicios, pues es posible definir como parámetros de entrada ciertas parte de la URL, lo que nos permite en primer lugar, crear métodos especiales para atender ciertas URL, pero por otra parte, esos fragmentos de URL pueden ser inyectados como parámetros a los métodos Java.

NOTA: Este artículo pertenece a una guia completa para aprender a crear un API REST con el API de JAX-RS de Java, ve el índice completo aquí.

Hace unos días escribía sobre la forma de escribir los Path y como podemos como podemos podíamos definir parámetros con la anotación @Path, puede regresara a la sección Introducción a las URL con @Path si quieres tener un poco más de contexto sobre lo que estaremos hablando esta sección.

Definiendo un Path Param

No vamos a entrar en mucho detalle sobre como definir un parámetro desde @Path pues ya lo explicamos en una sección pasado, pero si repasaremos como se hacia. 

@GET
@Path("/users/{userId}")
public Response findUserById(long userId) {}

Como podemos apreciar en el fragmento de código anterior, es posible definir ciertas secciones de una URL como parámetros, encerrando entre llaves ({userId}) la parte que queremos recuperar como parámetro desde Java. 

Recuperar una Path Param con @PathParam

Ya que hemos definido todas secciones de parámetros dentro del @Path, lo que seguirá es recuperarlos desde el método Java para poderlos utilizar, para ello, debemos de establecer la anotación @PathParam en cada uno de los parámetros del método Java sobre el cual queremos inyectar el valor.

@GET
@Path("/users/{userId}")
public Response findUserById(@PathParam("userId") long user) {
    System.out.println("UserID ==> " + user);
}

En el fragmento de código anterior, podemos apreciar como hemos establecido la anotación @PathParam para el parámetro user, el cual será inyectado con el valor del parámetro userId del @Path.

Recuperar un Path param mediante UriInfo

La segunda forma de recuperar un Path param es mediante la interface UriInfo, la cual es una interface que contiene todos los metadatos relacionados con la URL. Al ser una interface no puede ser instanciada, por lo que deberá ser inyectada para ser utilizada, vamos como sería:

@GET
@Path("uriInfo/{param1}")
public Response getUriInfo(@Context UriInfo uriInfo) {
    String param1 = uriInfo.getPathParameters().getFirst("param1");
    return Response.ok(param1).build();
}

La interface UriInfo proporciona el método getPathParameters que retorna una subclase de la interface java.util.Map con todos los parámetros, por lo que podemos iterar el nombre de los parámetros y sus valores, o podemos buscar directamente el valor de un parámetro mediante el método getFist. 
Al ejecutar el método anterior deberíamos tener como resultado el valor del parámetro param1, vamos el resultado:

Conclusiones

Los Path params son indispensables para definir de forma clara los recursos de tu API, pues evita tener que agregar parámetros de tipo Query, los cuales hacen que las URL sean complejas y difíciles de recordar, ademas de que no son agradables para SEO.

The post Path params con @PathParam appeared first on Oscar Blancarte - Software Architecture.

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.

The post Personalizar las relaciones con @JoinColumn appeared first on Oscar Blancarte - Software Architecture.

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.

The post Store Procedure con parámetros de salida appeared first on Oscar Blancarte - Software Architecture.

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í.

The post JPA, Hibernate VS JDBC appeared first on Oscar Blancarte - Software Architecture.