java - Spring+GWT o Spring vs GWT

requestfactory

Question

Fondo

Estoy en el medio de desarrollar una aplicación web utilizando GWT, Java y EclipseLink. Cada una de esas selecciones son elecciones que he hecho para implementar este programa. GWT es la única opción donde no hay una comprensión firme de lo que se compara exactamente con algo como Spring. Ahora mismo uso los widgets de GWT para implementar el cliente y GWT RequestFactory para implementar la comunicación servidor-cliente de las entidades de EclipseLink.

Puntos de vista

Entonces veo a GWT principalmente como una biblioteca de widgets con un marco simple para la comunicación servidor-cliente. Esta es la misma forma en que veo Spring, una biblioteca de widgets con un marco mucho más avanzado y complejo para controlar las comunicaciones servidor-cliente, con la posibilidad de que no implemente AJAX tan convenientemente como lo hace GWT.

Así que con esto en mente, veo a GWT como un trampolín para comprender y eventualmente trabajar con Spring. Sin embargo, al volver a buscar en este tema, he encontrado varios temas como este y el que parece ir en contra de las nociones originales de qué es Spring y qué significa para GWT.

Las preguntas

1. ¿Hay alguna idea errónea acerca de las opiniones sobre GWT y Spring? ¡Si es así, algunos breves puntos de guía sobre esto serían muy apreciados!
2. ¿Cuál sería la contraparte de los widgets de GWT en Spring Framework?
3. ¿Cuál sería la contraparte de GWT RequestFactory en Spring Framework?

Answer 1

Echa un vistazo a Objectify para su backend. Mucho más sencillo.

Answer 2

GWT no es una biblioteca de widgets, sino un marco completo para producir aplicaciones web completas que se ejecutan en el cliente en lugar del servidor. La diferencia básica es que spring (patrón MVC) está enfocado en el servidor, por lo que se conecta al ddbb, ejecuta la lógica de negocios y genera la vista para enviar al cliente, ya que GWT (patrón MVP) ejecuta el presentador en el navegador que produce el Ver, y simplemente se conecta al servidor para obtener resultados u objetos (métodos remotos).

Dijo que, dependiendo de su aplicación GWT, podría necesitar más o menos lógica en el lado del servidor, y otros elementos como ddbb, spring, etc.

La decisión sobre cuándo elegir GWT o cualquier otro marco depende de si necesita una aplicación rica (de escritorio) en el navegador.

Lógicamente, puede combinar GWT y Spring en cualquier nivel de complejidad, pero la forma lógica es otorgarle a Spring la responsabilidad del modelo de datos y su lógica empresarial, y GWT haciendo el resto.

La mejor manera de aprender esta combinación es explorar un pequeño proyecto generado con Spring-roo . Puede crear un proyecto completo con todo configurado para maven, spring, gwt, mvp y rf. Simplemente instale roo 1.2.2 y ejecute este conjunto de comandos en la consola roo:

project --topLevelPackage com.project.contacts
persistence setup --provider ECLIPSELINK --database HYPERSONIC_PERSISTENT
database properties set --key database.url --value jdbc:hsqldb:/var/tmp/contacts.db
entity jpa --class com.project.contacts.domain.Contact --testAutomatically
field string name --notNull --sizeMin 1 --sizeMax 30 --class ~.domain.Contact
field string surname --notNull --sizeMin 1 --sizeMax 30 --class ~.domain.Contact
field string phone --notNull --sizeMin 1 --sizeMax 15 --class ~.domain.Contact
web gwt setup
web gwt all --proxyPackage ~.client.proxy --requestPackage ~.client.request
quit

Entonces ejecuta

mvn gwt:run

El principal problema que veo con roo es que usa ''aspectj'' para actualizar la clase administrada cuando modifica el modelo, pero puede eliminar la dependencia de roo y los archivos aspectj usando eclipse una vez que se configuró su proyecto.

Answer 3

Realmente depende de cómo planea usar GWT en su aplicación.

GWT se utiliza mejor para aplicaciones web de una sola página de host.
Eso significa que toda la sincronización de flujo y la lógica de negocios se realiza en el lado del cliente utilizando GWT .
Aquí es donde GWT realmente brilla (ver here para más detalles).

Sin embargo, si sigue este camino, terminará con básicamente dos aplicaciones distintas. Tendrá un frontend desarrollado con GWT y un backend usando Spring, por ejemplo. Su backend (Spring o lo que use) solo actuará como un "almacenamiento de datos" que le proporcionará los datos que va a mostrar en su interfaz de GWT. Por lo tanto, es probable que no utilice ninguna de las funciones del Spring MVC''s .

Por supuesto, también puede usar Spring MVC y GWT solo para agregar la funcionalidad web 2.0ish a su sitio, pero para ese caso de uso, le recomendaría que use jQuery, Closure u otros marcos de trabajo de javascript.

A tus preguntas:

¿Hay alguna idea errónea acerca de las opiniones sobre GWT y Spring? ¡Si es así, algunos breves puntos de guía sobre esto serían muy apreciados!

Si utiliza GWT como se pretende (aplicaciones web de una sola página de host), no utilizará la parte MVC de Spring. Aún puede usar autorización , autenticación , ORM y muchos otros componentes del marco de Spring, sin embargo GWT maneja todas las vistas.
Spring actúa más o menos solo como un almacenamiento de datos para su aplicación de frontend de GWT. Es como tener dos aplicaciones distintas y separadas que están conectadas a través de un protocolo de comunicación ( RequestFactory , REST , RPC , etc.).

¿Cuál sería la contraparte de los widgets de GWT en Spring Framework?

No hay una contraparte real para los widgets de GWT en Spring Framework (tal vez para algunas extensiones JSF) Spring tiene que ver con el lado del servidor, por lo que todas las vistas se crean en el lado del servidor. Mientras que GWT tiene que ver con el lado del cliente.

¿Cuál sería la contraparte de GWT RequestFactory en Spring Framework?

RequestFactory es el protocolo de comunicación entre su aplicación frontend ( GWT ) y su aplicación backend ( Spring ). Cuando utiliza Spring MVC no necesita ningún protocolo de comunicación ya que las vistas se generan en el lado del servidor donde ya tiene los datos.