java - porque - jpa vs jdbc performance

Hibernate o JPA o JDBC o?

Question

Estoy desarrollando una aplicación de escritorio Java pero tengo algunas confusiones al elegir una tecnología para mi capa de persistencia.

Hasta ahora, he estado usando JDBC para operaciones DB. Ahora, recientemente aprendí Hibernate y JPA, pero todavía soy un novato en estas tecnologías.

Ahora mi pregunta es ¿Qué usar para mi aplicación de escritorio Java a partir de lo siguiente?

• JPA

• Hibernar

• JDBC

• DAO

• cualquier otra sugerencia de ti ...

Sé que no hay mejor opción para ellos y depende totalmente de la complejidad y los requisitos del proyecto, por lo que a continuación se detallan los requisitos de mi proyecto.

1. No es una aplicación compleja. Contiene solo 5 tablas (y 5 entidades)
2. Quiero que mi código sea flexible para poder cambiar la base de datos más tarde fácilmente
3. El tamaño de la aplicación debe ser lo más pequeño posible ya que tendré que distribuirlo a mis clientes a través de Internet.
4. Debe ser libre de usar en desarrollo comercial y distribución.

================================= EDITADO ============= =======================

Sobre la base de las respuestas a continuación, me gustaría ir con JPA para evitar escribir código SQL específico del proveedor.

Pero tengo algunos problemas en JPA que se mencionan en Java Persistence API

Answer 1

Aquí está mi opinión:

• JPA: forma agnóstica de hacer la persistencia de Java sin conectar a tus clientes a Hibernate, TopLink, etc.
• Hibernate: Buena opción si tiene un modelo de objetos para mapear.
• JDBC: toda la persistencia de Java se basa en esto. Nivel más bajo
• DAO: más de un patrón que una tecnología; Interfaz de operación CRUD.
• iBatis: A medio camino entre JDBC (SQL sin procesar) e Hibernate (ORM).
• JDO: Java Data Objects, que es otra especificación para la persistencia de Java. (por ejemplo, Apache JDO )

No es una aplicación compleja. Contiene solo 5 tablas (y 5 entidades)

Cualquiera de estos funcionará, pero JDBC será el más simple. Todos los demás están construidos sobre JDBC.

Quiero que mi código sea flexible para poder cambiar la base de datos más tarde fácilmente

Los cambios de esquema tendrán efectos similares en todas las tecnologías.

El tamaño de la aplicación debe ser lo más pequeño posible ya que tendré que distribuirlo a mis clientes a través de Internet.

El uso de JPA o Hibernate requerirá JAR que se agregarán al tamaño de su implementación. JDBC minimizará esto.

Debe ser libre de usar en desarrollo comercial y distribución.

Ver licencias de todas las tecnologías. No debería ser un problema con ninguno de ellos.

FYI: es posible escribir una interfaz DAO genérica:

package persistence;

import java.io.Serializable;
import java.util.List;

public interface GenericDao<T, K extends Serializable>
{
    T find(K id);
    List<T> find();
    List<T> find(T example);
    List<T> find(String queryName, String [] paramNames, Object [] bindValues);

    K save(T instance);
    void update(T instance);
    void delete(T instance);
}

Si tus objetos asignan 1: 1 con tus cinco tablas, diría que JPA es demasiado cuadrado.

¿Actualmente su aplicación está en el orden de 3MB JAR? Si no, entonces Hibernate o JPA duplicarán el tamaño. Puede cuantificar exactamente cuánto. Y hay más de un JAR, porque ambos tienen dependencias.

YAGNI dice que deberías mantenerlo simple. ¡Son cinco mesas!

Cambiar de proveedor, si lo hace correctamente, significa cambiar un JAR del controlador JDBC, cambiar el nombre de la clase de controlador y agregar la nueva URL de conexión, lo cual tiene que hacer sin importar qué tecnología elija.

Encuentro que las bases de datos no cambian tan radicalmente. ¿Cambiará el esquema, pero todo el proveedor? No es probable, especialmente si tiene varios clientes. Sería un gran inconveniente hacer que una base de datos de usuario cambie de base de datos.

¿Con cuál planeabas viajar? HSQL o algo que requerirá una instalación como MySQL? Esa es una preocupación más pertinente.

Answer 2

JPA es, sin duda, un camino a seguir si desea utilizar el mapeo de relaciones de objeto: es independiente de la implementación (lo que significa que puede usarlo con Hibernate, Toplink, etc.) y es el estándar de facto. Hibernate tiene un conjunto de funciones más completo, pero esta es una solución no estándar, aunque muchas personas lo usan ... Personalmente siempre uso JPA respaldado por Hibernate. Intento mantenerme alejado de las cosas específicas de hibernación, pero si lo necesito, está ahí para mí.

Sin embargo, usar un marco como JPA / Hibernate para 5 tablas puede ser un poco exagerado. Su aplicación será alrededor de 5MB más grande y consumirá una camada más de memoria. Simplemente puede optar por usar JDBC emparejado con DAO.

Dado que JDBC usa SQL que es específico del proveedor (base de datos), esto podría ser problemático si planea utilizar diferentes bases de datos. JPA tiene una clara ventaja en esta área.

Independientemente de lo que elija, no puede fallar; debe preguntarse, en su mayor parte, si el aumento del tamaño y el consumo de memoria es un problema, y ​​si está dispuesto a escribir un código descriptivo DAO JDBC. Generalmente odio esto :-)

Answer 3

Para esta escala, todo funcionará bien. Considera iBatis también.