Contrairement à RequestFactory qui a de mauvaises capacités de gestion des erreurs et de test (car il traite la plupart des choses sous le capot de GWT), RPC vous permet d'utiliser une approche plus orientée service. RequestFactory implémente une approche de style d'injection de dépendances plus moderne qui peut fournir une approche utile si vous devez appeler des structures de données polymorphes complexes. Lorsque vous utilisez RPC, vos structures de données devront être plus plates, car cela permettra à vos utilitaires de marshaling de traduire entre vos modèles json / xml et java. L'utilisation de RPC vous permet également de mettre en œuvre une architecture plus robuste, comme indiqué dans la section gwt dev sur le site Web de Google.
"Déploiement client / serveur simple
La première et la plus simple façon de penser aux définitions de service est de les traiter comme l'ensemble du back-end de votre application. De ce point de vue, le code côté client est votre "frontal" et tout le code de service qui s'exécute sur le serveur est "back-end". Si vous adoptez cette approche, vos implémentations de service auront tendance à être des API plus générales qui ne sont pas étroitement associées à une application spécifique. Vos définitions de service accèderaient probablement directement aux bases de données via JDBC ou Hibernate ou même à des fichiers dans le système de fichiers du serveur. Pour de nombreuses applications, cette vue est appropriée et elle peut être très efficace car elle réduit le nombre de niveaux.
Déploiement à plusieurs niveaux
Dans des architectures plus complexes et à plusieurs niveaux, vos définitions de service GWT peuvent simplement être des passerelles légères qui font appel à des environnements de serveurs principaux tels que des serveurs J2EE. De ce point de vue, vos services peuvent être considérés comme la «moitié serveur» de l'interface utilisateur de votre application. Au lieu d'être à usage général, les services sont créés pour les besoins spécifiques de votre interface utilisateur. Vos services deviennent le "frontal" des classes "back-end" qui sont écrites en assemblant des appels à une couche de services back-end plus générale, implémentée, par exemple, sous la forme d'un cluster de serveurs J2EE. Ce type d'architecture est approprié si vous avez besoin que vos services back-end s'exécutent sur un ordinateur physiquement séparé de votre serveur HTTP. "
Notez également que la mise en place d'un seul service RequestFactory nécessite de créer environ 6 classes java alors que RPC ne nécessite que 3. Plus de code == plus d'erreurs et de complexité dans mon livre.
RequestFactory a également un peu plus de temps système pendant le traitement de la demande, car il doit rassembler la sérialisation entre les proxys de données et les modèles Java réels. Cette interface ajoutée ajoute des cycles de traitement supplémentaires qui peuvent vraiment s'additionner dans une entreprise ou un environnement de production.
Je ne crois pas non plus que les services RequestFactory soient une sérialisation comme les services RPC.
Dans l'ensemble, après avoir utilisé les deux pendant un certain temps maintenant, j'utilise toujours RPC car il est plus léger, plus facile à tester et à déboguer, et plus rapide que l'utilisation d'une RequestFactory. Bien que RequestFactory puisse être plus élégant et extensible que son homologue RPC. La complexité supplémentaire n'en fait pas un meilleur outil nécessaire.
Mon avis est que la meilleure architecture consiste à utiliser deux applications Web, un client et un serveur. Le serveur est une simple application web java générique légère qui utilise la bibliothèque servlet.jar. Le client est GWT. Vous effectuez une requête RESTful via GWT-RPC dans le côté serveur de l'application Web cliente. Le côté serveur du client n'est qu'un passage vers le client Apache http qui utilise un tunnel persistant dans le gestionnaire de requêtes que vous exécutez en tant que servlet unique dans votre application Web de servlet serveur. L'application Web servlet doit contenir la couche d'application de votre base de données (hibernate, cayenne, sql, etc.). Cela vous permet de séparer complètement les modèles d'objet de base de données du client réel, offrant un moyen beaucoup plus extensible et robuste de développer et de tester l'unité de votre application. Certes, cela nécessite un peu de temps de configuration initiale, mais à la fin vous permet de créer une usine de requêtes dynamiques en dehors de GWT. Cela vous permet de tirer parti du meilleur des deux mondes. Sans oublier de pouvoir tester et apporter des modifications à votre serveur sans avoir à faire compiler ou construire le client gwt.