A diferencia de RequestFactory, que tiene pocas capacidades de prueba y manejo de errores (ya que procesa la mayoría de las cosas bajo el capó de GWT), RPC le permite utilizar un enfoque más orientado a servicios. RequestFactory implementa un enfoque de estilo de inyección de dependencia más moderno que puede proporcionar un enfoque útil si necesita invocar estructuras de datos polimórficas complejas. Cuando use RPC, sus estructuras de datos deberán ser más planas, ya que esto permitirá que sus utilidades de clasificación se traduzcan entre sus modelos json / xml y java. El uso de RPC también le permite implementar una arquitectura más robusta, como se cita en la sección gwt dev del sitio web de Google.
"Implementación simple de cliente / servidor
La primera y más sencilla forma de pensar en las definiciones de servicio es tratarlas como el back-end completo de su aplicación. Desde esta perspectiva, el código del lado del cliente es su "interfaz" y todo el código de servicio que se ejecuta en el servidor es "back-end". Si adopta este enfoque, las implementaciones de sus servicios tenderán a ser API de uso más general que no están estrechamente acopladas a una aplicación específica. Es probable que sus definiciones de servicio accedan directamente a las bases de datos a través de JDBC o Hibernate o incluso archivos en el sistema de archivos del servidor. Para muchas aplicaciones, esta vista es apropiada y puede ser muy eficiente porque reduce el número de niveles.
Implementación de varios niveles
En arquitecturas más complejas y de varios niveles, sus definiciones de servicio GWT podrían ser simplemente pasarelas ligeras que llaman a entornos de servidor back-end como servidores J2EE. Desde esta perspectiva, sus servicios pueden verse como la "mitad del servidor" de la interfaz de usuario de su aplicación. En lugar de ser de uso general, los servicios se crean para las necesidades específicas de su interfaz de usuario. Sus servicios se convierten en el "front-end" de las clases "back-end" que se escriben uniendo llamadas a una capa de servicios de back-end de uso más general, implementada, por ejemplo, como un clúster de servidores J2EE. Este tipo de arquitectura es apropiado si necesita que sus servicios de back-end se ejecuten en una computadora físicamente separada de su servidor HTTP ".
También tenga en cuenta que la configuración de un único servicio RequestFactory requiere la creación de alrededor de 6 o más clases de Java, mientras que RPC solo requiere 3. Más código == más errores y complejidad en mi libro.
RequestFactory también tiene un poco más de sobrecarga durante el procesamiento de la solicitud, ya que tiene que ordenar la serialización entre los proxies de datos y los modelos Java reales. Esta interfaz adicional agrega ciclos de procesamiento adicionales que realmente pueden sumarse en un entorno empresarial o de producción.
Tampoco creo que los servicios RequestFactory sean serialización como los servicios RPC.
En general, después de usar ambos durante algún tiempo, siempre opto por RPC porque es más liviano, más fácil de probar y depurar, y más rápido que usar RequestFactory. Aunque RequestFactory podría ser más elegante y extensible que su contraparte RPC. La complejidad añadida no la convierte en una herramienta mejor necesaria.
Mi opinión es que la mejor arquitectura es utilizar dos aplicaciones web, un cliente y un servidor. El servidor es una aplicación web java genérica y ligera que utiliza la biblioteca servlet.jar. El cliente es GWT. Realiza una solicitud RESTful a través de GWT-RPC en el lado del servidor de la aplicación web del cliente. El lado del servidor del cliente es solo un paso al cliente http de apache que usa un túnel persistente en el controlador de solicitudes que tiene ejecutándose como un solo servlet en su aplicación web de servlet del servidor. La aplicación web del servlet debe contener la capa de aplicación de la base de datos (hibernate, cayenne, sql, etc.). Esto le permite divorciar completamente los modelos de objetos de la base de datos del cliente real, lo que proporciona una forma mucho más extensible y robusta de desarrollar y realizar pruebas unitarias de su aplicación. De acuerdo, requiere un poco de tiempo de configuración inicial, pero al final le permite crear una fábrica de solicitudes dinámicas fuera de GWT. Esto le permite aprovechar lo mejor de ambos mundos. Sin mencionar la posibilidad de probar y realizar cambios en el lado del servidor sin tener que compilar o compilar el cliente gwt.