JDO vs JPA per Java su Google App Engine

StackOverflow https://stackoverflow.com/questions/1418219

Domanda

Voglio sviluppare il mio progetto su Google App Engine con Struts2. Per il database ho due opzioni JPA e JDO. Ragazzi, mi suggerirete, per favore? Entrambi sono nuovi per me e ho bisogno di impararli. Quindi mi concentrerò su uno dopo le tue risposte.

Grazie.

È stato utile?

Soluzione

JPA è lo standard di Sun per la persistenza, JDO sta morendo IMHO (in realtà, è morto ma si sta ancora muovendo). In altre parole, l'APP sembra essere un investimento migliore a lungo termine. Quindi immagino che sceglierei JPA se entrambi fossero nuovi per me.

Altri suggerimenti

Il gruppo google GAE / J ha diversi post su questa cosa. Farei una ricerca lì e guarderei le opinioni delle persone. Riceverai un messaggio molto diverso dalle opinioni espresse sopra. Concentrati anche sul fatto che BigTable non è un RDBMS. Usa lo strumento giusto per il lavoro

Ho appena visto questo confronto tra JPA e JDO dagli stessi DataNucleus: - http://www.datanucleus.org/products/accessplatform_2_1/jdo_jpa_faq.html Una rivelazione.

Sono un felice utente di JDO. Continuate così ragazzi.

Le persone che affermano che JDO è morto non sono prive di merito. Ecco cosa ho letto nel libro Pro EJB 3 Java Persistence API: "Poco dopo Sun ha annunciato che JDO sarebbe stato ridotto alla modalità di manutenzione delle specifiche e che l'API Java Persistence avrebbe attinto sia da JDO che dagli altri fornitori di persistenza e sarebbe diventato il singolo standard supportato andando avanti. " ;. L'autore Mike Keith è il leader della codecisione su EJB3. Ovviamente è un grande sostenitore dell'APP, ma dubito che sia abbastanza parziale da mentire.

È vero che quando il libro è stato pubblicato, la maggior parte dei principali venditori erano uniti dietro JPA piuttosto che JDO, anche se JDO ha caratteristiche tecniche più avanzate di JPA. Non è sorprendente perché i grandi attori del mondo EE come IBM / Oracle sono anche grandi fornitori di RDBMS. Più clienti utilizzano RDMBS rispetto a non RDMBS nei loro progetti. JDO stava morendo fino a quando GAE non ha dato una grande spinta. Ha senso perché l'archivio dati GAE non è un database relazionale. Alcune funzionalità di JPA non funzionano con bigtable come query di aggregazione, query Join, relazioni di proprietà molte-a-molte. A proposito, GAE supporta JDO 2.3 mentre supporta solo JPA 1.0. Consiglierò JDO se GAE è la tua piattaforma cloud di destinazione.

Per la cronaca, è Google App Engine (GAE), quindi giochiamo con le regole di Google non con le regole di Oracle / Sun.

Sotto di esso, JPA non è adatto per GAE, è instabile e non funziona come previsto. Né Google è disposto a supportarlo, ma il minimo indispensabile.

E per il resto, JDO è abbastanza stabile in GAE ed è (in alcuni casi) ben documentato da Google.

Tuttavia, Google non consiglia nessuno di essi.

http://code.google.com/appengine/docs/ java / datastore / overview.html

L'API di basso livello offre le migliori prestazioni e GAE è tutto sulle prestazioni.

http://gaejava.appspot.com/

Ad esempio, aggiungi 10 entità

  

Python: 68ms

     

JDO: 378ms

     

Java Native: 30ms

Nella gara tra JDO e JPA posso solo essere d'accordo con i poster dei datanucleus.

Prima di tutto, e soprattutto, i poster di Datanucleus sanno cosa stanno facendo. Dopotutto stanno sviluppando una libreria persistente e hanno familiarità con modelli di dati diversi da quelli relazionali, ad es. Tavolo grande. Sono sicuro che un id sviluppatore di ibernazione fosse qui, avrebbe detto: "tutti i nostri presupposti quando si costruiscono le nostre librerie di base sono strettamente accoppiati al modello relazionale, l'ibernazione non è ottimizzata per GAE".

In secondo luogo, JPA è senza dubbio in un uso più diffuso, essendo una parte dello stack Java EE ufficiale aiuta un po ', ma ciò non significa necessariamente che sia migliore. In effetti, JDO, se lo leggi, corrisponde a un livello di astrazione più elevato di JPA. JPA è strettamente associato al modello di dati RDBMS.

Dal punto di vista della programmazione, l'uso delle API JDO è un'opzione molto migliore, perché concettualmente stai compromettendo molto di meno. È possibile passare, teoricamente, a qualsiasi modello di dati desiderato, a condizione che il provider utilizzato supporti il ??database sottostante. (In pratica raramente raggiungi un livello di trasparenza così elevato, perché ti ritroverai a impostare le tue chiavi primarie sull'oggetto GAE e ti legherai a un provider di database specifico, ad esempio google). sarà comunque più facile migrare.

In terzo luogo, è possibile utilizzare Hibernate, Eclipse Link e persino spring con GAE. Google sembra aver fatto un grande sforzo per consentirti di utilizzare i framework su cui sei abituato a sviluppare le tue applicazioni. Ma ciò che le persone realizzano quando creano le loro applicazioni GAE come se fossero in esecuzione su RDBMS è che sono lente. La primavera su GAE è LENTO. Puoi google Google IO video su questo argomento per vedere che è vero.

Inoltre, aderire agli standard è una buona cosa sensata da fare, in linea di principio applaudo. D'altra parte, l'APP che fa parte dello stack Java EE fa perdere alle persone la nozione di opzioni. Se vuoi, renditi conto che anche Java Server Faces fa parte dello stack Java EE. Ed è una soluzione incredibilmente ordinata per lo sviluppo della GUI Web. Ma alla fine, perché le persone, le persone più intelligenti, se così posso dire, si discostano da questo standard e usano invece GWT?

In tutto ciò, devo accontentarmi del fatto che esiste una cosa molto significativa per l'APP. Questo è Guice e il suo comodo supporto per l'APP. Sembra che Google non sia stato intelligente come al solito in questo punto e sia contento, per ora non supporta JDO. Penso ancora che se lo possano permettere, e alla fine anche Guice inghiottirà JDO, ... o forse no.

Vai a JDO. Anche se non hai esperienza in esso, non è difficile da imparare e avrai una nuova abilità sotto la cintura!

Quello che penso sia terribile nell'usare JDO al momento della stesura di questo è che l'unico fornitore di implementazione è Datanucleus e gli svantaggi di ciò è la mancanza di concorrenza che porta a numerosi problemi come:

  1. Una documentazione non molto dettagliata su alcuni aspetti come extensions
  2. Di solito ricevi risposte sarcastiche dagli autori come (Hai controllato i registri? Potrebbe esserci un motivo per averli) e risposte fastidiose come quelle
  3. Non ricevi una risposta alla tua domanda in un periodo di tempo utile, a volte se ricevi una risposta in meno di 7 giorni, dovresti considerarti fortunato, anche qui su StackOverflow

Spero sempre che qualcuno inizi a implementare da solo la specifica JDO , magari offriranno qualcosa di più e, auspicabilmente, più gratuito attenzione alla comunità e non sempre preoccuparsi di essere pagato per il supporto, non dire che gli autori di Datanucleus si preoccupano solo del supporto commerciale, ma sto solo dicendo.

Personalmente ritengo che gli autori di Datanucleus non abbiano l'obbligo di Datanucleus né la propria comunità. Possono abbandonare l'intero progetto in qualsiasi momento e nessuno può giudicarli per questo, è il loro sforzo e le loro proprietà. Ma dovresti sapere in cosa ti stai cacciando. Vedi, quando uno di noi sviluppatori cerca un framework da usare, non puoi punire o comandare l'autore del framework, ma d'altra parte, hai bisogno che il tuo lavoro sia fatto! Se avessi il tempo di scrivere quel framework, perché dovresti cercarne uno in primo luogo?!

D'altra parte, JDO ha alcune complicazioni come il ciclo di vita degli oggetti e cose che non sono molto intuitive e comuni (penso).

Modifica: ora so anche che JPA applica il meccanismo del ciclo di vita degli oggetti, quindi sembra inevitabile gestire gli stati del ciclo di vita di entità persistenti se si desidera utilizzare un'API ORM standard (ovvero < codice> JPA o JDO )

Quello che mi piace di più di JDO è la capacità di lavorare con QUALSIASI sistema di gestione di database senza sforzi considerevoli.

GAE / J è in programma per aggiungere MYSQL entro la fine dell'anno.

JPA è la strada da percorrere in quanto sembra essere spinta come un'API standardizzata e ha recentemente avuto slancio in EJB3.0 .. JDO sembra aver perso il ritmo.

Nessuno dei due!

Usa Objectify, perché costa meno (usa meno risorse) ed è più veloce. Cordiali saluti: http://paulonjava.blogspot.mx/2010/12/tuning -Google-appengine.html

  

Objectify è un'API di accesso ai dati Java appositamente progettata per   Archivio dati di Google App Engine. Occupa una "via di mezzo"; più facile da   uso e più trasparente di JDO o JPA, ma significativamente più   conveniente rispetto all'API di basso livello. Objectify è progettato per essere realizzato   i novizi immediatamente produttivi ma espongono anche il pieno potere del   Archivio dati GAE.

Objectify ti consente di persistere, recuperare, eliminare e interrogare i tuoi oggetti digitati. 

@Entity
class Car {
    @Id String vin; // Can be Long, long, or String
    String color;
}

ofy().save().entity(new Car("123123", "red")).now();
Car c = ofy().load().type(Car.class).id("123123").now();
ofy().delete().entity(c);
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top