2012-08-09 19 views
67

Sto imparando Java EE e ho scaricato l'eclissi con glassfish per lo stesso. Ho visto alcuni esempi e ho anche letto i documenti Oracle per sapere tutto su Java EE 5. La connessione a un database era molto semplice. Ho aperto un progetto web dinamico, creato un bean di sessione, ho usato EntityManager e con i metodi get ho potuto accedere alla tabella dei dati memorizzati.JPA o JDBC, come sono diversi?

Per il mio prossimo progetto ho creato una classe semplice e quindi accesso ad alcune tabelle DB. Il primo problema che ho riscontrato era che l'attributo PersistenceUnit sarebbe stato riconosciuto solo da EJB, Servlet ecc. E non da una semplice classe java. Quindi non potrei usare il modo EntityManager (o posso?)

Mi è stato chiesto di passare attraverso il modo "JDBC". Il primo problema che ho riscontrato è stato ottenere la connessione al DB. Sembra che tutto questo debba essere scritto a mano. Ho avuto un persistence.xml con il quale ho potuto facilmente configurare la connessione del database. Anche impostare un driver per il DB è stato facile. Inoltre non ci sono metodi get/set nel JDBC per accedere alle entità della tabella.

Come faccio a capire JPA e persistenza in relazione a JDBC? Per cosa si pensava l'JPA? Perché ci sono metodi set/get? Qualcuno può far luce sull'essenza di questi due e quali sono i pro/contro senza "gerghi" ?? Si prega di suggerire anche alcuni collegamenti. Una semplice ricerca su Google per le differenze JPA e JDBC mi ha portato ad alcuni siti pieni di "terminologia" Non ho potuto seguire :(

+2

Perché non iniziare con il tutorial JDBC: http://docs.oracle.com/javase/tutorial/jdbc/index.html –

+1

JPA può essere utilizzato senza EJB o anche Java EE, è possibile creare un EntityManagerFactory direttamente da Persistenza . – James

risposta

132

termini di Layman:

  • JDBC è uno standard per l'accesso ai database
  • JPA è uno standard per ORM

JDBC è uno standard per la connessione a un DB direttamente e in esecuzione SQL contro di essa - per esempio SELECT * FROM USERS, ecc È possibile restituire set di dati che è possibile gestire nella propria app e si possono fare tutte le solite cose come INSERTS, DELETES, eseguire stored procedure, ecc. È una delle tecnologie alla base della maggior parte dell'accesso ai database java (compresi i provider JPA).

Uno dei problemi con tradizionali JDBC app è che spesso è possibile avere un po 'di codice di merda in cui un sacco di mapping tra i set di dati e gli oggetti si verificano, la logica è mescolati con SQL, ecc

JPA è uno standard per oggetto Mappatura relazionale. Questa è una tecnologia che ti consente di mappare gli oggetti nel codice e nelle tabelle del database. Questo può "nascondere" l'SQL dallo sviluppatore in modo che tutto ciò di cui hanno a che fare sono classi java, e il provider ti permette di salvarli e caricarli magicamente. Per lo più, i file di mappatura XML o le annotazioni su getter, setter possono essere utilizzati per comunicare al provider JPA quali campi del proprio oggetto mappano su quali campi del DB. Il più famoso provider JPA è Hibernate, quindi è un buon punto di partenza per esempi concreti.

http://www.hibernate.org/

Altri esempi includono OpenJPA, toplink, etc.

Sotto il cofano, Hibernate e la maggior parte degli altri provider di JPA scrivono SQL e utilizzano JDBC per leggere e scrivere sul DB.

+2

iBatis (al giorno d'oggi MyBatis) non è un'implementazione JPA. Se dai un'occhiata ad esso, noterai che ha un concetto molto diverso. –

+0

grazie! Il mio errore, ho pensato che fosse implementato JPA, corretto ora! –

+1

Non tutti i provider JPA scrivono SQL e utilizzano JDBC ... poiché potrebbero persistere in "un diverso tipo di datastore" (MongoDB, Neo4j, ecc.). DataNucleus JPA è uno di questi esempi – DataNucleus

31

principale differenza tra APP e JDBC è il livello di astrazione.

JDBC è un livello basso standard per l'interazione con i database JPA è lo standard di livello superiore per lo stesso scopo.JPA ti consente di utilizzare un modello di oggetti nella tua applicazione che può semplificarti la vita.JDBC ti permette di fare più cose direttamente con il Database, ma richiede più attenzione: alcune attività non possono essere risolte in modo efficiente con JPA, ma possono essere risolte in modo più efficiente con JDBC

6

JDBC è il predecessore di JPA.

JDBC è un ponte tra il mondo Java e il mondo dei database. In JDBC è necessario esporre tutti i dettagli sporchi necessari per le operazioni CRUD, come i nomi delle tabelle, i nomi delle colonne, mentre in JPA (che sta usando JDBC sotto), si specificano anche i dettagli dei metadati del database, ma con l'uso delle annotazioni Java.

Così JPA crea query di aggiornamento per te e gestisce le entità che hai cercato o creato/aggiornato (fa anche di più).

Se si desidera eseguire JPA senza un contenitore Java EE, Spring e le sue librerie possono essere utilizzate con le stesse annotazioni Java.

+0

"senza un contenitore Java EE ??" Intendi Spring e le sue librerie sono indipendenti dal web container? –

+0

@BruceZu Certo che lo è. È possibile utilizzare molti componenti del framework Spring senza la necessità di un contenitore Web. L'iniezione di dipendenza, ad esempio, non è qualcosa che ti serve solo in un contesto web. – Dolfiz

12

JDBC è una specifica molto più bassa (e meno recente) di JPA. Nella sua essenza, JDBC è un'API per interagire con un database usando puro SQL - inviando query e recuperando i risultati. Non ha idea di oggetti o gerarchie. Quando si utilizza JDBC, spetta a te tradurre un set di risultati (essenzialmente una matrice di righe/colonne di valori da una o più tabelle di database, restituite dalla query SQL) in oggetti Java.

Ora, per comprendere e utilizzare JDBC è essenziale disporre di una conoscenza e di una conoscenza pratica di SQL. Con ciò viene anche richiesto un approfondimento su cosa sia un database relazionale, come si lavora con esso e concetti come tabelle, colonne, chiavi e relazioni. A meno che tu non abbia almeno una conoscenza di base dei database, della modellazione SQL e dei dati, non sarai in grado di fare molto uso di JDBC dato che in realtà è solo una sottile astrazione su queste cose.