Pregunta

¿Ha intentado usar MVC o cualquier otro patrón de UI para el código de cliente GWT? ¿Cuáles son los riesgos / ventajas que ha enfrentado en diferentes enfoques?

¿Fue útil?

Solución

Creo que debe tratar GWT como cualquier otro marco de UI, como Swing, Cocoa, etc. Todo lo que tenga sentido en esos marcos en términos de MVC (u otros paradigmas) también tiene sentido en GWT. Creo que a veces la gente toma el MVC demasiado lejos, y me gusta la forma en que funciona en Cocoa más que la mayoría de los marcos. Creas una vista, tienes un ViewController que controla todo el comportamiento de la vista, y luego tienes objetos modelo con todos tus datos. No creo que debas ser dogmáticos sobre dónde está toda la lógica de tu negocio, solo tiene que estar donde tenga sentido.

En cuanto a las trampas, el principal problema con el que se encontrará es que GWT es puramente una tecnología de front-end, por lo que técnicamente el back-end está ubicado en un servidor en algún lugar. No veo que esto sea tan diferente a escribir una aplicación de swing de servidor de cliente, que almacena sus datos en la nube en algún lugar. La diferencia es que GWT está compilado en javascript y tiene todas las limitaciones de una aplicación web de javascript, por lo que habrá algunas cosas que simplemente no puede hacer en la parte frontal. Digamos, por ejemplo, que desea crear un PDF y mostrarle al usuario que no puede hacer eso en GWT, necesita llamar al back end para que lo haga por usted. Por otro lado, en una aplicación Swing, probablemente podría usar itext y hacerlo en el lado del cliente.

Otros consejos

El patrón MVC para GWT se describe en esta pregunta , que también tiene un enlace a esta información en profundidad publicación de blog .

Lo único que agregaría es que el código del lado del cliente en su totalidad se puede considerar el " V " en " MVC " ;, que puede alterar la forma en que lo miras. Pensando en el código del lado del cliente como su propio componente MVC anidado, bueno, es Java, está orientado a objetos, por lo que puede diseñarse como una aplicación Swing. Creo que es una ventaja para usted sacar todo el código del Controlador de la Vista como sea posible para manejar las cosas de GWT RPC. El modelo a veces es más problemático, porque es posible que tenga que decidir si lo quiere en el servidor en lugar del cliente. O crea un modelo de proxy, etc.

http://code.google.com/p/gwt-mvc/ podría ayudarte.

Las ventajas son:

  • controlador fácil de leer
  • Gestión de tokens de historia
  • Los controladores se pueden probar con JMock (pero no con GwtTestCase)
  • MVC jerárquico
  • Herencia simple para comenzar a codificar su vista, controladores y modelos.

¿Has probado GWTruts ( http://sourceforge.net/projects/gwtruts/ ) ? También es un marco de GWT MVC de código abierto que separa la vista y el controlador en GWT

El uso de algún tipo de patrón de tipo MVC / MVP es realmente importante cuando las aplicaciones GWT van más allá del proyecto más pequeño, sino que simplemente pierdes el control de lo que está pasando.

Aparte de lo que ya se ha mencionado, también hay una implementación MVC de GXT que he visto aquí: http://www.bristol-gtug.org/?p=45

Esta charla en Google IO el año pasado hizo que muchas personas pensaran en MVC / MVP en GWT: http://code.google.com/events/io/2009/sessions/GoogleWebToolkitBestPractices.html .

Hace poco noté que también hay un tutorial sobre la arquitectura MVP en la documentación de GWT, que es un buen comienzo: http://code.google.com/webtoolkit/doc/latest/tutorial/mvp-architecture.html

Puede echar un vistazo a JetPad-Mappers, un marco MVC minimalista desarrollado en JetBrains y utilizado en varios productos (actualmente no publicados).

Descargo de responsabilidad, estoy involucrado en el desarrollo de este marco.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top