JPA o JDBC, ¿en qué se diferencian?

119

Estoy aprendiendo Java EE y descargué el eclipse con glassfish para el mismo. Vi algunos ejemplos y también leí los documentos de Oracle para saber todo sobre Java EE 5. La conexión a una base de datos fue muy simple. Abrí un proyecto web dinámico, creé una sesión EJB, usé EntityManager y con los métodos get pude acceder a la tabla de datos almacenados.

Para mi próximo proyecto, tuve que crear una clase simple y luego acceder a una tabla de base de datos. El primer problema que encontré fue que el atributo PersistenceUnit solo sería reconocido por EJB, Servlet, etc. y no por una simple clase Java. Entonces, no pude usar la forma EntityManager (¿o puedo?)

Se me pidió que pasara por la vía "JDBC". El primer problema que encontré fue conseguir la conexión a la base de datos. Parece que todo esto debe estar codificado. Tenía un persistence.xml con el que podía configurar fácilmente la conexión de la base de datos. Incluso configurar un controlador para la base de datos fue fácil. Además, no hay métodos get / set en JDBC para acceder a las entidades de la tabla.

¿Cómo entiendo JPA y la persistencia en relación con JDBC? ¿Para qué se pensó JPA? ¿Por qué hay métodos set / get? ¿Alguien puede arrojar algo de luz sobre la esencia de estos dos y cuáles son los pros / contras sin "jergas"? Sugiera también algunos enlaces. Una simple búsqueda en Google de las diferencias entre JPA y JDBC me llevó a algunos sitios llenos de "terminología" que no podía seguir :(

user907810
fuente
2
Por qué no comenzar con el tutorial de JDBC: docs.oracle.com/javase/tutorial/jdbc/index.html
a_horse_with_no_name
2
JPA se puede utilizar sin EJB o incluso Java EE, puede crear un EntityManagerFactory directamente desde Persistence.
James

Respuestas:

237

En términos simples:

  • JDBC es un estándar para el acceso a bases de datos
  • JPA es un estándar para ORM

JDBC es el estándar para conectar a una base de datos SQL directamente y funcionando en su contra - por ejemplo SELECT * FROM USERS, etc. Los conjuntos de datos pueden ser devueltos que se puede manejar en su aplicación, y se puede hacer todas las cosas habituales como INSERT, DELETE, ejecutar procedimientos almacenados, etc. Es una de las tecnologías subyacentes detrás de la mayoría de los accesos a bases de datos de Java (incluidos los proveedores de JPA).

Uno de los problemas con las aplicaciones JDBC tradicionales es que a menudo puede tener un código de mierda donde ocurren muchos mapeos entre conjuntos de datos y objetos, la lógica se mezcla con SQL, etc.

JPA es un estándar para el mapeo relacional de objetos. Esta es una tecnología que le permite mapear entre objetos en código y tablas de base de datos. Esto puede "ocultar" el SQL al desarrollador para que todo lo que se ocupe sean las clases de Java, y el proveedor le permite guardarlas y cargarlas mágicamente. En su mayoría, los archivos de mapeo XML o las anotaciones en captadores y definidores se pueden usar para decirle al proveedor de JPA qué campos en su objeto se asignan a qué campos en la base de datos. El proveedor de JPA más famoso es Hibernate , por lo que es un buen lugar para comenzar con ejemplos concretos.

Otros ejemplos incluyen OpenJPA, toplink, etc.

Bajo el capó, Hibernate y la mayoría de los otros proveedores de JPA escriben SQL y usan JDBC para leer y escribir desde y hacia la base de datos.

Mark D
fuente
3
iBatis (hoy MyBatis) no es una implementación de JPA. Si le echas un vistazo, notarás que tiene un concepto muy diferente.
Mikko Maunu
¡Gracias! Mi error, pensé que implementó JPA, ¡corregido ahora!
Mark D
3
No todos los proveedores de JPA escriben SQL y usan JDBC ... ya que pueden persistir en un "tipo diferente de almacén de datos" (MongoDB, Neo4j, etc.). DataNucleus JPA es un ejemplo
DataNucleus
cierto DataNucleus ... incluso hay algunos para excel, etc. Las preguntas originales eran JDBC / JPA, así que asumí, con razón o sin ella, que estaba interesado en las tiendas relacionales.
Mark D
52

La principal diferencia entre JPA y JDBC es el nivel de abstracción.

JDBC es un estándar de bajo nivel para la interacción con bases de datos. JPA es un estándar de nivel superior para el mismo propósito. JPA le permite utilizar un modelo de objetos en su aplicación que puede hacer su vida mucho más fácil. JDBC le permite hacer más cosas con la base de datos directamente, pero requiere más atención. Algunas tareas no se pueden resolver de manera eficiente usando JPA, pero pueden resolverse de manera más eficiente con JDBC.

gkuzmin
fuente
20

JDBC es una especificación de nivel mucho más bajo (y más antigua) que JPA. En lo esencial, JDBC es una API para interactuar con una base de datos usando SQL puro: enviar consultas y recuperar resultados. No tiene noción de objetos ni jerarquías. Al usar JDBC, depende de usted traducir un conjunto de resultados (esencialmente una matriz de valores de fila / columna de una o más tablas de base de datos, devuelta por su consulta SQL) en objetos Java.

Ahora, para comprender y usar JDBC es esencial que tenga cierta comprensión y conocimiento práctico de SQL. Con eso también viene una información necesaria sobre qué es una base de datos relacional, cómo trabaja con ella y conceptos como tablas, columnas, claves y relaciones. A menos que tenga al menos un conocimiento básico de bases de datos, SQL y modelado de datos, no podrá hacer mucho uso de JDBC, ya que en realidad es solo una pequeña abstracción además de estas cosas.

papilla
fuente
10

JDBC es el predecesor de JPA.

JDBC es un puente entre el mundo de Java y el mundo de las bases de datos. En JDBC, debe exponer todos los detalles sucios necesarios para las operaciones CRUD, como nombres de tablas, nombres de columnas, mientras que en JPA (que usa JDBC debajo), también especifica esos detalles de los metadatos de la base de datos, pero con el uso de anotaciones Java.

Entonces JPA crea consultas de actualización para usted y administra las entidades que buscó o creó / actualizó (también hace más).

Si desea hacer JPA sin un contenedor Java EE, entonces Spring y sus bibliotecas pueden usarse con las mismas anotaciones Java.

Pawel Solarski
fuente
"¿sin un contenedor Java EE?" ¿Quiere decir que Spring y sus bibliotecas son independientes del contenedor web?
Bruce Zu
@BruceZu Por supuesto que lo es. Puede utilizar muchos de los componentes del marco de Spring sin necesidad de un contenedor web. La inyección de dependencia, por ejemplo, no es algo que solo necesite en un contexto web.
Dolfiz
1
@Dolfiz, ¿no son las bibliotecas web de primavera una envoltura de las bibliotecas Java Web y Java EE?
raikumardipak