patron mvc modelo diferencia model-view-controller architecture gwt mvp puremvc

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



mvvm vs mvc (5)

Acabo de iniciar un nuevo proyecto GWT para un cliente y estoy interesado en escuchar la experiencia de las personas con varias arquitecturas GWT MVC. En un proyecto reciente, utilicé tanto GXT MVC como una solución de mensajería personalizada (basada en MQ de Appcelerator ). GXT MVC funcionaba bien, pero parecía exagerado para GWT y era 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, he escuchado que Google Wave (una aplicación GWT) está escrita usando un patrón Model-View-Presenter. Recientemente se publicó una aplicación MVP de muestra , pero al mirar el código, no parece tan intuitivo.

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

Gracias,

Mate

Deberías echar un vistazo a los portlets de GWT . Desarrollamos el Marco de Portlets de GWT mientras trabajábamos en una gran aplicación de Portal de Recursos Humanos y ahora es de código abierto y gratuito. 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 de GWT como una biblioteca. La funcionalidad de la aplicación se desarrolla como Portlets ligeramente acoplados, cada uno con un DataProvider opcional del lado del servidor.

Cada portlet sabe cómo externalizar su estado en una subclase de PortletFactory serializable (patrón de momento / DTO / fábrica) que hace 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 organizar a / desde XML en el servidor, para almacenar diseños de GUI (o "páginas") en archivos de páginas 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 marcos.
  • Los portlets están posicionados de forma absoluta, por lo que pueden usar regiones de desplazamiento
  • Los portlets son configurables, indican cuando están ocupados cargando para la visualización automática de "carga del rotor" y se pueden maximizar
  • Widgets temáticos que incluyen un cuadro de diálogo con estilo, un reemplazo de botón de estilo CSS, botones de herramientas pequeños y un menú impulsado por una plantilla HTML

GWT Portlets está implementado en código Java y no envuelve ninguna biblioteca Javascript externa. 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.

Me alegro de que se haya formulado esta pregunta, porque GWT desesperadamente necesita una forma de estructurar una aplicación. Un enfoque simple basado en las mejores prácticas que funcionará en el 90% de todos los casos de uso y permite una capacidad de prueba muy sencilla.

En los últimos años he estado usando mi propia implementación de MVP con una visión muy pasiva que se esclaviza a lo que el presentador le pida 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 un Composite o usar una biblioteca de widgets externa
  • un Presentador central para una pantalla que aloja N vistas que están compuestas de M widgets
  • un modelo central por pantalla que contiene los datos asociados con la apariencia visual actual
  • clases genéricas de escuchas como "SourcesAddEvents [CustomerDTO]" (al editor no le gustan los símbolos reales para los genéricos de Java aquí, así que usé los paréntesis), porque de lo contrario tendrá muchas interfaces iguales que solo difieren por 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á a otros widgets / vistas y / o llamará a gwt-rpc que, en caso de éxito, coloca su resultado en el modelo. El modelo tiene un mecanismo de detector de cambio de propiedad "Propiedad [Lista [Cadena]] nombres = ...." que está registrado con el presentador, de modo que la actualización de un modelo por una solicitud gwt-rpc va a todas las vistas / widgets que estan interesados.

Con este appraoch he conseguido una capacidad de prueba muy fácil con EasyMock para mis AsynInterfaces. También obtuve 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 notificaba al presentador de algún evento, independientemente del widget subyacente (botón, enlaces, etc.).

Problemas con mi enfoque:

  • Mi implementación actual hace que sea difícil sincronizar 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. En la actualidad, es muy difícil propagar esos eventos de cambio a través de los límites de las pantallas, porque los valores están en caché en esos modelos y es difícil encontrar si algunas cosas están sucias (habría sido fácil en un web1.0-html tradicional). tipo de escenario de terminal de conmutación con almacenamiento en caché declarativo en el servidor).
  • Los parámetros de constructor de las vistas permiten realizar pruebas muy sencillas, pero sin un marco sólido de Dependencia-Inyección, uno tendrá un código de fábrica / configuración FEBRERO dentro de "onModuleLoad ()". En el momento en que comencé esto, no estaba al tanto de Google GIN, así que cuando refactorice mi aplicación, la usaré para deshacerme de esta repetición. Un ejemplo interesante aquí es el juego "HigherLower" dentro del GIN-Trunk.
  • No obtuve Historia correctamente la primera vez, por lo que es difícil navegar de una parte de mi aplicación a otra. Mi enfoque no es consciente de la historia, que es una recesión grave.

Mis soluciones a esos problemas:

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

Resumen:

No creo que se pueda usar un solo enfoque de "MVP" para una aplicación completa. Uno definitivamente necesita historial para la navegación de aplicaciones, un bus de eventos como GXT-MVC para adjuntar / separar pantallas, y MVP para permitir pruebas fáciles de acceso a datos para widgets.

Por lo tanto, propongo un enfoque en capas que combine estos tres elementos, ya que creo que la solución "one-event-mvp-system" no funcionará. Navegación / Conexión de pantalla / Acceso a datos son tres preocupaciones diferentes y voy a refactorizar mi aplicación (pasar a GXT) en los próximos meses para utilizar los tres marcos de eventos para cada problema por separado (la mejor herramienta para el trabajo). Los tres elementos no necesitan estar conscientes el uno del otro. Sé que mi solución solo se aplica a los proyectos GXT.

Cuando escribo grandes aplicaciones GWT, siento que tengo que reinventar algo como Spring-MVC en el cliente, lo que realmente apesta, ya que toma mucho tiempo y capacidad cerebral escupir algo elegante como Spring MVC. GWT necesita un framework de aplicaciones mucho más que esas pequeñas y pequeñas optimizaciones JS en las que los compiladores trabajan tan duro.

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