2009-04-14 24 views
17

Me gustaría desarrollar una aplicación web que requiera la persistencia de datos usando GWT y GAE. Según tengo entendido, mi única (o al menos la opción más conveniente) para la persistencia de datos es el Almacén de datos de GAE, que utiliza objetos anotados JDO o JPA. También me gustaría poder enviar mis objetos hacia adelante y hacia atrás cliente-servidor usando GWT llamadas a procedimiento remoto (RPC), por lo tanto, mis objetos deben ser capaces de "separar". Sin embargo, la serialización GWT RPC no puede manejar objetos separados JDO/JPA y no parece que lo será en el futuro cercano.Google Web Toolkit (GWT) + Google App Engine (GAE) + Persistencia de datos separados

Mi pregunta: ¿cuál es la solución más simple y directa para esto? Ser capaz de compartir los mismos objetos cliente/servidor con persistencia del lado del servidor sería extremadamente conveniente.

EDITAR

Debo aclarar que aún deseo utilizar GWT RPC con el almacén de datos de GAE. Solo busco la mejor solución que permita que todas estas tecnologías trabajen juntas.

+0

+1 para usar un servicio basado en web de clustering para la persistencia de datos locales. :-) –

+1

¿Consideraría compartir su progreso en esto después de obtener respuestas aquí? (y por favor, considere seleccionar la mejor respuesta) –

Respuesta

0

ya que GWT finalmente compila a JavaScript, para persistencia separada necesitaría uno de los pocos servicios disponibles. las más conocidas son tiendas HTML5 y Gears (¡ambos usan SQLite!). por supuesto, ninguno de los dos está ampliamente implementado, por lo que tendrá que convencer a sus usuarios de que utilicen un navegador moderno o instalen un complemento poco conocido. asegúrese de degradar a un subconjunto útil si el usuario no cumple

+0

Por separado, están hablando de enviar hibernación, etc., dtos mejorados, no persistencia en el navegador. –

+0

caso típico de colisión de términos. – Javier

3

hace un rato me ha escrito una entrada Using an ORM or plain SQL?

Esto ocurrió el año pasado en una aplicación GWT estaba escribiendo. Muchos de traducción de EclipseLink a objetos de presentación en el servicio implementación. Si estuviéramos utilizando ibatis habría sido mucho más simple crear los objetos apropiados con ibatis y luego pasarlos por todo el camino arriba y abajo de la pila. Algunos puristas podrían argumentar que esto es Bad ™. Tal vez sea así (en la teoría ), pero le diré algo: habría llevado a un código más simple, una pila más simple y más productividad.

que básicamente coincide con su observación.

Pero, por supuesto, esa no es una opción con Google App Engine, por lo que está bastante atrapado en tener una capa de traducción entre los objetos del lado del cliente y sus entidades JPA.

Las entidades JPA son bastante rígidas, por lo que no son realmente apropiadas para enviar y recibir clientes. Normalmente, desea pequeños bits de varias entidades al hacer esto (por lo que termina con algún tipo de objeto de valor de capa de presentación). Ese es tu camino hacia adelante.

2

Puede considerar el uso de JSON. GWT tiene API necesaria para analizar & generar cadena JSON en el lado del cliente. Obtienes una gran cantidad de API JSON para el lado del servidor. Intenté con google-gson, que está bien. Convierte su cadena JSON al modelo POJO y viceversa. Espero que esto le ayuda a proporcionar una solución decente para su requerimiento

7
+0

Más específicamente, el Adapter4AppEngine http://noon.gilead.free.fr/gilead/index.php?page=adapter4appengine Tenga en cuenta que no todos los tipos de JDO de Google se serializarán. Texto, Blob y Usuario por ejemplo. Todavía necesitarás sortear esto de otra manera. – Drew

5

Ray Cromwell tiene una temporary hack up. Lo probé y funciona.

Te obliga a usar transitorios en lugar de entidades desmontables, porque GWT no puede serializar un objeto oculto [] utilizado por DataNucleus; Esto significa que los objetos que envía al cliente no se pueden volver a insertar en el almacén de datos, debe recuperar el objeto de almacén de datos real y copiar nuevamente todos los campos persistentes. El método de Ray utiliza la reflexión para iterar sobre los métodos, recupera los métodos getBean() y setBean(), y aplica la entidad setBean() con getBean() de su objeto transient gwt.

Debe esforzarse por utilizar JDO, el JPA no es mucho más que una clase contenedora por el momento. Para utilizar este truco, debe tener tanto métodos getter como setter para cada campo persistente, utilizando la sintaxis apropiada getBean y setBean para cada campo "bean". Bueno, ALMOST PROPER, ya que supone que todos los getters comenzarán con "get", cuando el campo Boolean predeterminado es "is".

He solucionado este problema y he publicado un comentario en el blog de Ray, pero está en espera de aprobación y no estoy seguro de si lo publicará. Básicamente, implementé una anotación @GetterPrefix (prefix = MethodPrefix.IS) en el paquete org.datanucleus para aumentar su trabajo.

En caso de que no se publique, y esto es un problema, envíe un correo electrónico a x_AT_aiyx_DOT_info Re: @GetterPrefix para JDO y le enviaré la solución.

3

Try this. Es un módulo para serializar tipos de núcleos GAE y enviarlos al cliente GWT.

2

Actualmente, utilizo el patrón DTO (DataTransferObject). No necesariamente tan limpio y mucho más repetitivo, pero GAE aún requiere una buena cantidad de repetición a la fecha. ;)

Tengo un objeto de dominio mapeado (generalmente) uno a uno con un DTO. Cuando un cliente necesita información de dominio, un DAO (DataAccessObject) arroja una representación de DTO del objeto de dominio y lo envía a través del cable. Cuando regresa un DTO, entrego el DAO al DTO que luego actualiza todos los objetos de dominio apropiados.

No es tan limpio como poder pasar Domain Objects directamente a través del cable, obviamente, pero las limitaciones de la implementación de JE de GAE y el proceso de serialización de GWT significa que esta es la forma más limpia de manejar esto actualmente.

0

¿Qué tal el uso directo de Datastore API para cargar/almacenar objetos de dominio POJO?

Debe ser comparable al enfoque DTO, es decir, p. Ej. que tiene que manejar manualmente todos los campos (si no usa trucos como la automatización basada en la reflexión) mientras que debería darle más flexibilidad y acceso completo a todas las características del Almacén de datos.

5

Recientemente he encontrado Objectify, que está diseñado para ser un reemplazo de JDO. Todavía no tengo mucha experiencia, pero es más fácil de usar que JDO, parece más liviano y pretende evitar la necesidad de DTO con GWT, aunque todavía no lo he probado.

1

He estado usando Objectify también, y realmente me gusta. Todavía tiene que bailotear con los métodos pre/postload para traducir, p. Ej. Texto a cadena y vuelta.

2

Creo que la respuesta oficial de Google para esto es GWT 2.1 RequestFactory. Dado que está utilizando GWT y GAE, le sugiero que se adhiera al marco oficial de Google ... Tengo una aplicación similar basada en GWT/GAE y eso es lo que estoy haciendo.

Por cierto, configurar RequestFactory es un poco molesto.El complemento Eclipse actual no incluye todos los archivos jar pero pude encontrar la ayuda que necesitaba, en Stackoverflow