¿Cuál es su recomendación para diseñar aplicaciones GWT? ¿MVC, MVP o solución de mensajería personalizada?

Question

Acabo de comenzar un nuevo proyecto de GWT para un cliente y estoy interesado en escuchar la experiencia de las personas con varias arquitecturas de GWT MVC. En un proyecto reciente, utilicé GXT MVC , así como una solución de mensajería personalizada (basada en MQ de Appcelerator ). GXT MVC funcionó bien, pero parecía excesivo para GWT y fue difícil trabajar con el historial del navegador. He oído hablar de PureMVC y GWTiger , pero nunca los usó. Nuestra solución MQ personalizada funcionó bastante bien, pero dificultó la prueba de componentes con JUnit.

Además, escuché que Google Wave (una aplicación GWT) está escrito usando un patrón Modelo-Vista-Presentador. Recientemente se publicó una aplicación MVP de muestra , pero mirando el código, no lo hace parece tan intuitivo.

Si estuviera creando una nueva aplicación GWT, ¿qué arquitectura usaría? ¿Cuáles son los pros y los contras de su elección?

Gracias,

Matt

Answer 1

Vale la pena señalar que Google finalmente ha escrito un tutorial para diseñar usando la arquitectura mvp. Aclara muchos de los elementos de Google I / O Talk mencionados anteriormente. Eche un vistazo: https://developers.google.com/web-toolkit/articles / mvp-architecture

Answer 2

Me alegra que se haya hecho esta pregunta, porque GWT necesita una forma de estructurar una aplicación similar a un riel. Un enfoque simple basado en las mejores prácticas que funcionará para el 90% de todos los casos de uso y permite una capacidad de prueba súper fácil.

En los últimos años, he estado usando mi propia implementación de MVP con una visión muy pasiva que se esclaviza de lo que el presentador le dice que haga.

Mi solución consistió en lo siguiente:

• una interfaz por widget que define los métodos para controlar la apariencia visual
• una clase de implementación que puede ser Compuesta o usar una biblioteca de widgets externos
• un presentador central para una pantalla que aloja N vistas que están formadas por widgets M
• un modelo central por pantalla que contiene los datos asociados con la apariencia visual actual
• clases de escucha genéricas como " SourcesAddEvents [CustomerDTO] " (al editor no le gustan los símbolos reales para los genéricos de Java aquí, así que utilicé los corchetes), porque de lo contrario tendrá muchas de las mismas interfaces que solo difieren según el tipo

Las Vistas obtienen una referencia al presentador como su parámetro constructor, por lo que pueden inicializar sus eventos con el presentador. El presentador manejará esos eventos y notificará otros widgets / vistas y / o llamará a gwt-rpc que, en caso de éxito, coloca su resultado en el modelo. El modelo tiene un típico " Property [List [String]] names = .... " mecanismo de escucha de cambio de propiedad que está registrado con el presentador para que la actualización de un modelo mediante una solicitud gwt-rpc vaya a todas las vistas / widgets que estén interesados.

Con este appraoch he conseguido una prueba muy fácil con EasyMock para mis AsynInterfaces. También tuve la capacidad de intercambiar fácilmente la implementación de una vista / widget, porque todo lo que tuve que reescribir fue el código que notificó al presentador de algún evento, independientemente del widget subyacente (Botón, Enlaces, etc.).

Problemas con mi enfoque:

• Mi implementación actual dificulta la sincronización de valores de datos entre los modelos centrales de diferentes pantallas. Supongamos que tiene una pantalla que muestra un conjunto de categorías y otra pantalla que le permite agregar / editar esos elementos. Actualmente es muy difícil propagar esos eventos de cambio a través de los límites de las pantallas, porque los valores se almacenan en caché en esos modelos y es difícil determinar si algunas cosas están sucias (habría sido fácil en una web tradicional 1.0-html -dumb-terminal tipo de escenario con almacenamiento en caché declarativo del lado del servidor).
• Los parámetros del constructor de las vistas permiten una prueba súper fácil, pero sin un marco sólido de Inyección de Dependencia, uno tendrá algún código UGLY de fábrica / configuración dentro de "onModuleLoad ()". En el momento en que comencé esto, no tenía conocimiento de Google GIN, así que cuando refactorice mi aplicación, la usaré para deshacerme de esta repetitiva. Un ejemplo interesante aquí es el " HigherLower " juego dentro del GIN-Trunk.
• No obtuve el historial correctamente la primera vez, por lo que es difícil navegar de una parte de mi aplicación a otra. Mi enfoque no tiene conocimiento de la historia, que es una grave recesión.

Mis soluciones a esos problemas:

• Use GIN para eliminar la placa de configuración que es difícil de mantener
• Al pasar de Gwt-Ext a GXT, use su marco MVC como EventBus para conectar / desconectar pantallas modulares, para evitar los problemas de almacenamiento en caché / sincronización
• Piense en algún tipo de "Lugar" -Abstracción como Ray Ryan describió en su charla en I / O 09, que cierra la brecha de eventos entre GXT-MVC y el enfoque GWTs-Hitory
• Use MVP para widgets para aislar el acceso a datos

Resumen:

No creo que se pueda usar un solo '' MVP '' enfoque para una aplicación completa. Definitivamente se necesita un historial para la navegación de aplicaciones, un bus de eventos como GXT-MVC para conectar / desconectar pantallas y MVP para permitir una prueba fácil de

Answer 3

Aquí hay una presentación reciente de Google IO en arquitectura de su aplicación GWT .

Disfruta.

-JP

Answer 4

Si está interesado en utilizar la arquitectura MVP, puede consultar GWTP: http://code.google.com/p/gwt-platform/ . Es un marco MVP de código abierto en el que estoy trabajando, que admite muchas características agradables de GWT, incluida la división de código y la gestión del historial, con una API simple basada en anotaciones. Es bastante reciente, pero ya se está utilizando en varios proyectos.

Answer 5

Debería echar un vistazo a Portlets GWT . Desarrollamos el marco de portlets GWT mientras trabajábamos en una gran aplicación de portal de recursos humanos y ahora es gratuita y de código abierto. Desde el sitio web de GWT Portlets (alojado en el código de Google):

El modelo de programación es algo similar a escribir portlets JSR168 para un servidor de portal (Liferay, JBoss Portal, etc.). El " portal " es su aplicación creada utilizando el marco de portlets GWT como biblioteca. La funcionalidad de la aplicación se desarrolla como Portlets acoplados libremente, cada uno con un DataProvider opcional del lado del servidor.

Cada Portlet sabe cómo externalizar su estado en una subclase de PortletFactory serializable (momento / DTO / patrón de fábrica) haciendo posible una funcionalidad importante:

• Las operaciones CRUD son manejadas por un solo GWT RPC para todos los portlets
• El diseño de los portlets en una " página " se puede representar como un árbol de WidgetFactory (una interfaz implementada por PortletFactory)
• Los árboles de WidgetFactory se pueden serializar y ordenar a / desde XML en el servidor, para almacenar diseños de GUI (o '' páginas '') en archivos de página XML

Otras características importantes del marco se enumeran a continuación:

• Las páginas se pueden editar en el navegador en tiempo de ejecución (por desarrolladores y / o usuarios) utilizando el editor de diseño de marco
• Los portlets están posicionados absolutamente para que puedan usar regiones de desplazamiento
• Los portlets son configurables, indican cuándo están ocupados cargando para el " spinner de carga " automático mostrar y se puede maximizar
• Widgets temáticos que incluyen un cuadro de diálogo con estilo, un reemplazo de botón con estilo CSS, pequeños botones de herramientas y un menú dirigido por plantilla HTML

GWT Portlets está implementado en código Java y no incluye ninguna biblioteca externa de Javascript. No impone ningún marco del lado del servidor (por ejemplo, Spring o J2EE), pero está diseñado para funcionar bien en conjunto con dichos marcos.