JDO vs JPA para Java en Google App Engine

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

Pregunta

Quiero desarrollar mi proyecto en Google App Engine con Struts2. Para la base de datos tengo dos opciones JPA y JDO. ¿Me podrían sugerir, por favor? Ambos son nuevos para mí y necesito aprenderlos. Así que me concentraré en uno después de sus respuestas.

Gracias.

¿Fue útil?

Solución

JPA es el estándar de persistencia de Sun, JDO está muriendo en mi humilde opinión (en realidad, está muerto pero aún en movimiento). En otras palabras, JPA parece ser una mejor inversión a largo plazo. Así que supongo que elegiría JPA si ambos fueran nuevos para mí.

Otros consejos

El grupo de google GAE / J tiene varias publicaciones sobre esto mismo. Buscaría allí y vería las opiniones de la gente. Recibirá un mensaje muy diferente a las opiniones expresadas anteriormente. También enfóquese en el hecho de que BigTable no es un RDBMS. Use la herramienta adecuada para el trabajo

Acabo de ver esta comparación entre JPA y JDO por DataNucleus: - http://www.datanucleus.org/products/accessplatform_2_1/jdo_jpa_faq.html Una revelación.

Soy un usuario feliz de JDO. Sigan con el buen trabajo chicos.

Las personas que afirman que JDO está muerto no carecen de mérito. Esto es lo que leí en el libro Pro EJB 3 Java Persistence API: " Poco después, Sun anunció que JDO se reduciría al modo de mantenimiento de especificación y que la API de Java Persistence se basaría tanto en JDO como en los otros proveedores de persistencia y se convertiría en el único estándar admitido en el futuro. '' El autor Mike Keith es el líder de la coespecificación en EJB3. Por supuesto, él es un gran defensor de JPA, pero dudo que sea tan parcial como para mentir.

Es cierto que cuando se publicó el libro, la mayoría de los principales proveedores se unieron detrás de JPA en lugar de JDO, a pesar de que JDO tiene características técnicas más avanzadas que JPA. No es sorprendente porque los grandes jugadores en el mundo de EE como IBM / Oracle también son grandes proveedores de RDBMS. Más clientes están utilizando RDMBS que no RDMBS en sus proyectos. JDO estaba muriendo hasta que GAE le dio un gran impulso. Tiene sentido porque el almacén de datos GAE no es una base de datos relacional. Algunas características de JPA no funcionan con bigtable, como consultas de agregación, consultas de unión, relaciones de muchos a muchos. Por cierto, GAE admite JDO 2.3 mientras que solo admite JPA 1.0. Recomendaré JDO si GAE es su plataforma de nube objetivo.

Para el registro, es Google App Engine (GAE), por lo que jugamos con las reglas de Google, no con las reglas de Oracle / Sun.

Debajo, JPA no es adecuado para GAE, es inestable y no funciona como se esperaba. Ni Google está dispuesto a apoyarlo, sino el mínimo.

Y por otra parte, JDO es bastante estable en GAE y está (en cierta medida) bien documentado por Google.

Sin embargo, Google no recomienda ninguno de ellos.

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

La API de bajo nivel proporcionará el mejor rendimiento y GAE tiene que ver con el rendimiento.

http://gaejava.appspot.com/

Por ejemplo, agregue 10 entidades

  

Python: 68ms

     

JDO: 378 ms

     

Java Native: 30 ms

En la carrera entre JDO vs JPA, solo puedo estar de acuerdo con los carteles del núcleo de datos.

En primer lugar, y también lo más importante, los carteles de datanucleus saben lo que están haciendo. Después de todo, están desarrollando una biblioteca persistente y están familiarizados con modelos de datos distintos al relacional, p. Mesa grande. Estoy seguro de que si un desarrollador de hibernate estuviera aquí, diría: "todas nuestras suposiciones al construir nuestras bibliotecas centrales están estrechamente relacionadas con el modelo relacional, hibernate no está optimizado para GAE".

En segundo lugar, JPA es, sin duda, un uso más extendido, ser parte de la pila oficial de Java EE ayuda un poco, pero eso no significa necesariamente que sea mejor. De hecho, JDO, si lo lee, corresponde a un nivel de abstracción más alto que JPA. JPA está estrechamente acoplado al modelo de datos RDBMS.

Desde el punto de vista de la programación, el uso de las API de JDO es una opción mucho mejor, porque conceptualmente compromete mucho menos. Puede cambiar, teóricamente, a cualquier modelo de datos que desee, siempre que el proveedor que utilice sea compatible con la base de datos subyacente. (En la práctica, rara vez se alcanza un nivel tan alto de transparencia, porque se encontrará configurando sus claves principales en el objeto de GAE y se vinculará a un proveedor de base de datos específico, por ejemplo, google). Sin embargo, aún será más fácil migrar.

En tercer lugar, puede usar Hibernate, Eclipse Link e incluso saltar con GAE. Google parece haber hecho un gran esfuerzo para permitirle usar los marcos en los que está acostumbrado a construir sus aplicaciones. Pero lo que la gente se da cuenta cuando construyen sus aplicaciones GAE como si se estuvieran ejecutando en RDBMS es que son lentas. Spring on GAE es LENTO. Puede buscar en Google videos de Google IO sobre este tema para ver si es cierto.

Además, cumplir con los estándares es algo sensato, en principio aplaudo. Por otro lado, JPA como parte de la pila Java EE hace que las personas, a veces, pierdan su noción de opciones. Tenga en cuenta, si lo desea, que Java Server Faces también forma parte de la pila Java EE. Y es una solución increíblemente ordenada para el desarrollo de GUI web. Pero al final, ¿por qué las personas, las personas más inteligentes si puedo decirlo, se desvían de este estándar y usan GWT en su lugar?

En todo esto, tengo que decir que hay algo muy importante para JPA. Esa es Guice y su conveniente soporte para JPA. Parece que google no era tan inteligente como de costumbre en este punto y están contentos, por ahora no admiten JDO. Todavía creo que pueden permitírselo, y eventualmente Guice engullirá a JDO también ... o tal vez no.

Ve a JDO. Incluso si no tienes experiencia en él, no es difícil de aprender, ¡y tendrás una nueva habilidad en tu haber!

Lo que creo que es terrible sobre el uso de JDO al momento de escribir esto es que el único proveedor de implementación es Datanucleus y los inconvenientes son la falta de competencia que conduce a numerosos problemas como:

  1. Una documentación no muy detallada sobre algunos aspectos, como extensions
  2. Usualmente obtienes respuestas sarcásticas de los autores como (¿Has revisado los registros? Puede haber una razón para tenerlos) y respuestas molestas como esa
  3. No recibe una respuesta a su pregunta en un período de tiempo útil, a veces, si obtiene una respuesta en menos de 7 días, debe considerarse afortunado, incluso aquí en StackOverflow

Siempre espero que alguien comience a implementar la especificación JDO ellos mismos, puede ser que entonces ofrezcan algo más y con suerte más atención gratuita a la comunidad y no siempre se preocupa por recibir un pago por el soporte, no digo que los autores de Datanucleus solo se preocupen por el soporte comercial, pero solo digo.

Personalmente considero que los autores de Datanucleus no tienen obligación alguna de Datanucleus ni de su comunidad. Pueden abandonar todo el proyecto en cualquier momento y nadie puede juzgarlos por ello, es su esfuerzo y su propia propiedad. Pero debes saber en lo que te estás metiendo. Verá, cuando uno de los desarrolladores busca un marco para usar, no puede castigar o mandar al autor del marco, pero por otro lado, ¡necesita que se haga su trabajo! Si tuviera tiempo para escribir ese marco, ¿por qué buscaría uno en primer lugar?

Por otro lado, JDO en sí tiene algunas complicaciones, como el ciclo de vida de los objetos y cosas que no son muy intuitivas y comunes (creo).

Editar: ahora sé que también JPA aplica el mecanismo del ciclo de vida del objeto, por lo que parece inevitable tratar con estados de ciclo de vida de entidades persistentes si desea utilizar una API ORM estándar (es decir, < code> JPA o JDO )

Lo que más me gusta de JDO es la capacidad de trabajar con CUALQUIER sistema de administración de bases de datos sin un esfuerzo considerable.

GAE / J está programado para agregar MYSQL antes de fin de año.

JPA es el camino a seguir, ya que parece ser empujado como una API estandarizada y recientemente ha cobrado impulso en EJB3.0 .. JDO parece haber perdido el impulso.

¡Ninguno!

Use Objectify, porque es más barato (usa menos recursos) y es más rápido. FYI: http://paulonjava.blogspot.mx/2010/12/tuning -google-appengine.html

  

Objectify es una API de acceso a datos Java diseñada específicamente para   Almacén de datos de Google App Engine. Ocupa un `` término medio ''; más fácil   uso y más transparente que JDO o JPA, pero significativamente más   conveniente que la API de bajo nivel. Objectify está diseñado para hacer   los novatos inmediatamente productivos pero también exponen todo el poder de la   Almacén de datos de GAE.

Objectify le permite persistir, recuperar, eliminar y consultar sus propios objetos escritos. 

@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);
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top