java - Spring+GWT o Spring vs GWT




requestfactory (2)

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

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?

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.





requestfactory