Envío de instancias JDO persistentes a través de GWT-RPC

Question

Acabo de empezar a aprender Google Web Toolkit y he terminado de escribir la aplicación tutorial Stock Watcher.

¿Es mi pensamiento correcto que si se quiere conservar un objeto de negocio (como un archivo) usando JDO y enviarlo ida y vuelta a/desde el cliente a través de RPC entonces uno tiene que crear dos clases separadas para ese objeto: ¿uno con las anotaciones JDO para persistirlo en el servidor y otro que se puede serializar y usar sobre RPC?

puedo tener la Bolsa de Vigía tiene clases separadas y puedo teorizar por qué:

• De lo contrario el compilador GWT trataría para generar Javascript para todo la clase PERSISTED referenciado como JDO y com.google.blah .users.User, etc.
• También puede haber lógica en la clase del lado del servidor que no se aplica al cliente y viceversa.

Solo quiero asegurarme de que estoy entendiendo esto correctamente. No quiero tener que crear dos versiones de todas mis clases de objeto de negocio que quiero usar sobre RPC si no tengo que llamar al.

Answer 1

No tiene que crear instancias separadas, de hecho es mejor que no lo haga. Sus objetos JDO deben ser POJO simples de todos modos, y nunca deben contener lógica comercial. Eso es para su capa de negocios, no sus propios objetos persistentes.

Todo lo que necesita hacer es incluir la fuente para las anotaciones que está utilizando y GWT debe compilar su clase muy bien. Además, desea evitar el uso de bibliotecas que GWT no puede compilar (como cosas que usan el reflejo, etc.), pero en todos los proyectos que he hecho esto nunca ha sido un problema.

Answer 2

Su opinión es correcta. JDO reemplaza las instancias de Colecciones con sus propias implementaciones, para poder oler cuándo cambia el gráfico del objeto, supongo. Estas implementaciones no son conocidas por el compilador GWT, por lo que no podrá serializarlas. Esto sucede a menudo para las clases que están compuestas de tipos compatibles con GWT, pero con anotaciones JDO, especialmente si algunas de las propiedades del objeto son Colecciones.

Para una explicación detallada y una solución alternativa, echa un vistazo a este ensayo muy influyente sobre el tema: http://timepedia.blogspot.com/2009/04/google-appengine-and-gwt-now-marriage.html

Answer 3

La respuesta corta es: que no es necesario para crear clases duplicadas.

recomiendo que eche un vistazo a la siguiente google grupos de discusión en la lista de GWT-colaboradores:

http://groups.google.com/group/google-web-toolkit-contributors/browse_thread/thread/3c768d8d33bfb1dc/5a38aa812c0ac52b

He aquí un extracto interesante:

Si esto es todo lo Estoy interesado en, I describió una forma de hacer que GAE y GWT-RPC trabajen juntos "fuera de la casilla ".Sólo declarar sus entidades como: @PersistenceCapable (identitytype = IdentityType.APPLICATION, desmontable = "false") public class MyPojo implementa Serializable {}

y todo funcionará, pero tendrá que hacer frente manualmente con reencadenamiento al enviar objetos desde el cliente al servidor.

Puede usar esta opción y no necesitará una clase espejo (DTO). También puede probar gilead (former hibernate4gwt), que se ocupa de algunos detalles dentro de los problemas de serialización de objetos mejorados.

Answer 4

No tiene que crear dos versiones del modelo de dominio.

He aquí dos consejos:

utilizar una clave de cadena codificada, no la clase Key AppEngine.

pojo = pm.detachCopy(pojo) 

... eliminará todas las mejoras de JDO.

Answer 5

Finalmente encontré una solución. No cambie su objeto en absoluto, pero para el listado hacerlo de esta manera:

List<YourCustomObject> secureList=(List<YourCustomObject>)pm.newQuery(query).execute(); 
return new ArrayList<YourCustomObject>(secureList); 

El problema real no es en números de serie a los objetos ... el problema es serializar la clase de colección que está implementado por Google y no puede serializar.

Answer 6

Creo que un mejor formato para enviar objetos a través de GWT es a través de JSON. En este caso, desde el servidor se enviaría una cadena JSON que luego tendría que analizarse en el cliente. La ventaja es que el Javascript final que se representa en el navegador tiene un tamaño más pequeño. lo que hace que la página se cargue más rápido.

En segundo lugar para enviar objetos a través de GWT, los objetos deben ser serializables. Esto puede no ser el caso para todos los objetos

En tercer lugar GWT ha incorporado funciones para manejar JSON ... así que no hay problemas en el cliente final