Ao contrário do RequestFactory, que tem recursos de teste e tratamento de erros pobres (uma vez que processa a maioria das coisas sob o capô do GWT), o RPC permite que você use uma abordagem mais orientada a serviços. RequestFactory implementa uma abordagem estilizada de injeção de dependência mais moderna que pode fornecer uma abordagem útil se você precisar invocar estruturas de dados polimórficas complexas. Ao usar RPC, suas estruturas de dados precisarão ser mais planas, pois isso permitirá que seus utilitários de empacotamento traduzam entre seus modelos json / xml e java. Usar o RPC também permite implementar uma arquitetura mais robusta, conforme citado na seção gwt dev no site do Google.
"Implementação Cliente / Servidor Simples
A primeira e mais direta maneira de pensar nas definições de serviço é tratá-las como todo o back-end do aplicativo. Dessa perspectiva, o código do lado do cliente é o seu "front end" e todo o código de serviço executado no servidor é o "back end". Se você adotar essa abordagem, suas implementações de serviço tendem a ser APIs de uso geral que não estão fortemente acopladas a um aplicativo específico. É provável que suas definições de serviço acessem diretamente bancos de dados por meio de JDBC ou Hibernate ou até mesmo arquivos no sistema de arquivos do servidor. Para muitos aplicativos, essa visualização é apropriada e pode ser muito eficiente porque reduz o número de camadas.
Implantação Multi-Tier
Em arquiteturas mais complexas e com várias camadas, suas definições de serviço GWT podem ser simplesmente gateways leves que chamam para ambientes de servidor de backend, como servidores J2EE. Dessa perspectiva, seus serviços podem ser vistos como a "metade do servidor" da interface de usuário do seu aplicativo. Em vez de serem de uso geral, os serviços são criados para as necessidades específicas de sua interface de usuário. Seus serviços se tornam o "front end" para as classes de "back end" que são escritas juntando chamadas para uma camada de serviços de backend de propósito geral, implementada, por exemplo, como um cluster de servidores J2EE. Esse tipo de arquitetura é apropriado se você precisar que seus serviços de back-end sejam executados em um computador fisicamente separado do servidor HTTP. "
Observe também que a configuração de um único serviço RequestFactory requer a criação de cerca de 6 classes java, enquanto o RPC requer apenas 3. Mais código == mais erros e complexidade em meu livro.
RequestFactory também tem um pouco mais de sobrecarga durante o processamento da solicitação, pois precisa organizar a serialização entre os proxies de dados e os modelos java reais. Essa interface adicionada adiciona ciclos de processamento extras que podem realmente ser adicionados em um ambiente corporativo ou de produção.
Também não acredito que os serviços RequestFactory sejam serialização como os serviços RPC.
Resumindo, depois de usar os dois por algum tempo, sempre uso o RPC, pois é mais leve, mais fácil de testar e depurar e mais rápido do que usar um RequestFactory. Embora RequestFactory possa ser mais elegante e extensível do que sua contraparte RPC. A complexidade adicional não o torna uma ferramenta melhor necessária.
Minha opinião é que a melhor arquitetura é usar dois aplicativos web, um cliente e um servidor. O servidor é um aplicativo da web java genérico simples e leve que usa a biblioteca servlet.jar. O cliente é GWT. Você faz uma solicitação RESTful via GWT-RPC no lado do servidor do aplicativo da Web do cliente. O lado do servidor do cliente é apenas uma passagem para o cliente Apache http, que usa um túnel persistente para o manipulador de solicitações que você está executando como um único servlet em seu aplicativo da web de servlet do servidor. O aplicativo da web de servlet deve conter sua camada de aplicativo de banco de dados (hibernate, cayenne, sql etc.). Isso permite que você divorcie totalmente os modelos de objeto de banco de dados do cliente real, proporcionando uma maneira muito mais extensível e robusta de desenvolver e testar a unidade de seu aplicativo. Concedido, requer um pouco de tempo de configuração inicial, mas, no final, permite que você crie uma fábrica de solicitações dinâmicas fora do GWT. Isso permite que você aproveite o melhor dos dois mundos. Sem mencionar ser capaz de testar e fazer alterações no lado do servidor sem ter que compilar ou construir o cliente gwt.