google-app-engine - flexible - google app engine installation
Google Web Toolkit(GWT)+Google App Engine(GAE)+persistencia de datos separados (11)
Me gustaría desarrollar una aplicación web que requiera la persistencia de datos utilizando 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 de un lado a otro cliente-servidor utilizando las Llamadas a procedimiento remoto (RPC) de GWT, por lo que mis objetos deben poder "separarse". Sin embargo, la serialización GWT RPC no puede manejar objetos JDO / JPA desconectados y no parece que lo hará en un futuro próximo.
Mi pregunta: ¿cuál es la solución más simple y directa a esto? Sería muy conveniente poder compartir los mismos objetos cliente / servidor con la persistencia del lado del servidor.
EDITAR
Debo aclarar que todavía deseo usar GWT RPC con el almacén de datos de GAE. Solo estoy buscando la mejor solución que permita que todas estas tecnologías trabajen juntas.
¿Qué pasa con el uso directo de la API del almacén de datos para cargar / almacenar objetos de dominio POJO?
Debería ser comparable al enfoque DTO, es decir, por ejemplo, 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 funciones del almacén de datos.
Actualmente, uso el patrón DTO (DataTransferObject). No necesariamente tan limpio y mucho más repetitivo, pero GAE todavía requiere una buena cantidad de repetitivo al momento. ;)
Tengo un objeto de dominio asignado (generalmente) uno a uno con un DTO. Cuando un cliente necesita información de dominio, un DAO (DataAccessObject) tose una representación DTO del objeto de dominio y lo envía a través del cable. Cuando un DTO vuelve, le doy al DAO el DTO que luego actualiza todos los objetos de dominio apropiados.
Obviamente, no es tan limpio como poder pasar objetos de dominio directamente a través del cable, pero las limitaciones de la implementación de JDO de GAE y el proceso de serialización de GWT significan que esta es la forma más limpia de manejar esto actualmente.
Creo que la respuesta oficial de Google para esto es GWT 2.1 RequestFactory . Dado que estás utilizando GWT y GAE, te sugiero que te limites 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 de dolor en el culo. El plugin actual de Eclipse no incluye todos los archivos jar pero pude encontrar la ayuda que necesitaba, en
Dado que GWT finalmente compila a JavaScript, para la persistencia desapegada necesitaría uno de los pocos servicios disponibles. Las más conocidas son las tiendas HTML5 y Gears (¡ambas usan SQLite!). por supuesto, ninguno de los dos se implementa ampliamente, por lo que tendrá que convencer a sus usuarios de que utilicen un navegador moderno o instalen un complemento poco conocido. asegúrese de degradarse a un subconjunto utilizable si el usuario no cumple
Hace un tiempo escribí una publicación ¿ Usando un ORM o SQL simple?
Esto surgió el año pasado en una aplicación GWT que estaba escribiendo. Mucha traducción de EclipseLink a objetos de presentación en la implementación del servicio. Si estuviéramos usando ibatis, habría sido mucho más sencillo crear los objetos adecuados con ibatis y luego pasarlos de arriba a abajo de la pila. Algunos puristas podrían argumentar que esto es malo ™. Tal vez sea así (en teoría), pero te digo qué: 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 atascado al 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 el envío entre el cliente de todos modos. Por lo general, se desean pequeños bits de varias entidades cuando se hace esto (por lo tanto, se termina con algún tipo de objeto de valor de capa de presentación). Ese es tu camino hacia adelante.
Puedes considerar usar JSON. GWT tiene la API necesaria para analizar y generar una cadena JSON en el lado del cliente. Se obtiene una gran cantidad de API JSON para el lado del servidor. Lo intenté con google-gson, lo cual está bien. Convierte tu cadena JSON al modelo POJO y viceversa. Espero que esto le ayude a proporcionar una solución decente para sus necesidades.
Ray Cromwell tiene un hackeo temporal . Lo he intentado, y funciona.
Te obliga a usar entidades Transitorias en lugar de 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 del almacén de datos real y copiar todos los campos persistentes en él. El método de Ray usa la reflexión para iterar sobre los métodos, recuperar los métodos getBean () y setBean (), y aplicar la entidad setBean () con el objeto getBean () de su objeto transitorio gwt.
Debería esforzarse por usar JDO, la JPA no es mucho más que una clase envoltura por ahora. Para usar este truco, debe tener métodos de obtención y establecimiento para cada campo persistente, utilizando la sintaxis de getBean y setBean APROPIADA para cada campo "bean". Bueno, CASI APROPIADO, ya que asume que todos los captadores comenzarán con "obtener", cuando el uso del campo booleano predeterminado es "es".
He solucionado este problema y he publicado un comentario en el blog de Ray, pero está pendiente 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 corrección.
Recientemente he encontrado Objectify , que está diseñado para ser un reemplazo para JDO. Aún no tengo mucha experiencia, pero es más sencillo de usar que JDO, parece más liviano y afirma que evita la necesidad de DTO con GWT, aunque todavía no he probado esa característica en particular.
También he estado usando Objectify, y realmente me gusta. Todavía tiene que bailar un poco con métodos pre / postLoad para traducir, por ejemplo, Texto a cadena y viceversa.
Trate de usar http://gilead.sourceforge.net/
Prueba esto Es un módulo para serializar los tipos de núcleo de GAE y enviarlos al cliente de GWT.