Quand dois-je utiliser RequestFactory vs GWT-RPC ?

Question

J'essaie de savoir si je dois migrer mes appels gwt-rpc vers les nouveaux appels RequestFactory de GWT2.1.

La documentation de Google mentionne vaguement que RequestFactory est une meilleure méthode de communication client-serveur pour les "services orientés données".

Ce que je peux tirer de la documentation, c'est qu'il existe une nouvelle classe Proxy qui simplifie la communication (vous ne transmettez pas l'entité réelle, mais seulement le proxy, ce qui allège le poids et facilite la gestion).

Est-ce là tout le problème ou est-ce que je rate quelque chose d'autre dans le tableau d'ensemble ?

Answer 1

La grande différence entre GWT RPC et RequestFactory est que le système RPC est "RPC-by-concrete-type" alors que RequestFactory est "RPC-by-interface".

RPC est plus pratique pour commencer, car vous écrivez moins de lignes de code et utilisez la même classe sur le client et le serveur. Vous pouvez créer un Person avec un tas de getters et setters et peut-être une logique d'entreprise simple pour un découpage plus poussé des données dans la classe Person objet. Cela fonctionne très bien jusqu'à ce que vous souhaitiez avoir du code spécifique au serveur, non compatible avec la GWT, dans votre classe. Parce que le système RPC est basé sur le fait d'avoir le même type concret à la fois sur le client et le serveur, vous pouvez vous heurter à un mur de complexité basé sur les capacités de votre client GWT.

Pour contourner l'utilisation d'un code incompatible, de nombreux utilisateurs finissent par créer un code d'égal à égal. PersonDTO qui fait de l'ombre au vrai Person utilisé sur le serveur. Le site PersonDTO a juste un sous-ensemble des getters et setters du côté serveur, "domain", Person objet. Maintenant, vous devez écrire du code qui transporte les données entre les objets Person y PersonDTO et tous les autres types d'objets que vous souhaitez transmettre au client.

RequestFactory commence par supposer que vos objets de domaine ne vont pas être compatibles avec GWT. Vous déclarez simplement les propriétés qui doivent être lues et écrites par le code client dans une interface Proxy, et les composants du serveur RequestFactory se chargent de mettre en forme les données et d'invoquer vos méthodes de service. Pour les applications qui ont un concept bien défini d'"Entités" ou d'"Objets avec identité et version", le module EntityProxy est utilisé pour exposer la sémantique de l'identité persistante de vos données au code client. Les objets simples sont mappés en utilisant le type ValueProxy type.

Avec RequestFactory, vous payez un coût initial de démarrage pour accueillir des systèmes plus compliqués que ceux que GWT RPC supporte facilement. La solution RequestFactory ServiceLayer fournit beaucoup plus de crochets pour personnaliser son comportement en ajoutant ServiceLayerDecorator instances.

Answer 2

J'ai vécu une transition de RPC à RF. D'abord je dois dire que mon expérience est limitée dans la mesure où, j'ai utilisé autant d'EntityProxies que de 0.

Avantages de GWT RPC :

• Il est très facile à configurer, à comprendre et à APPRENDRE !
• Les mêmes objets basés sur les classes sont utilisés sur le client et sur le serveur.
• Cette approche permet d'économiser des tonnes de code.
• Idéalement, lorsque les mêmes objets de modèle (et POJOS) sont utilisés sur le client et le serveur, POJOs == MODEL OBJECTs == DTOs
• Il est facile de déplacer des éléments du serveur au client.
• Il est facile de partager la mise en œuvre d'une logique commune entre le client et le serveur (ce qui peut s'avérer un inconvénient majeur lorsque vous avez besoin d'une logique différente).

Inconvénients de GWT RPC :

• Impossible d'avoir une implémentation différente de certaines méthodes pour le serveur et le client, par exemple, vous pourriez avoir besoin d'utiliser un cadre de journalisation différent sur le client et le serveur, ou une méthode différente pour les égaux.
• VRAIE MAUVAISE implémentation qui n'est pas plus extensible : la plupart des fonctionnalités du serveur sont implémentées comme des méthodes statiques sur une classe RPC. ÇA CRAINT VRAIMENT.
• Par exemple, il est impossible d'ajouter une obfuscation des erreurs côté serveur.
• Quelques problèmes de sécurité XSS qui ne sont pas résolus de manière élégante, voir la documentation (je ne suis pas sûr que ce soit plus élégant pour RequestFactory).

Inconvénients de RequestFactory :

• VRAIMENT DIFFICILE à comprendre à partir du document officiel, quel en est le mérite ! Cela commence dès le terme PROXIES qui est complètement trompeur - ce sont en fait des DTOs de RF qui sont créés automatiquement par RF. Les proxies sont définis par des interfaces, par exemple @ProxyFor(Journal.class). L'IDE vérifie s'il existe des méthodes correspondantes sur Journal. Voilà pour le mappage.
• RF ne vous apportera pas grand-chose en termes de points communs entre le client et le serveur car
• Sur le client, vous devez convertir les "PROXIES" en objets de votre domaine client et vice-versa. C'est complètement ridicule. Cela pourrait être fait en quelques lignes de code de manière déclarative, mais il n'y a aucun support pour cela ! Si seulement nous pouvions faire correspondre nos objets de domaine aux proxies de manière plus élégante, quelque chose comme la méthode JavaScript JSON.stringify(..,,) manque dans la boîte à outils de RF.
• N'oubliez pas que vous êtes également responsable de la définition des propriétés transférables de vos objets de domaine aux proxies, et ainsi de suite de manière récursive.
• MAUVAISE GESTION DES ERREURS sur le serveur et - Les traces de pile sont omises par défaut sur le serveur et vous obtenez des exceptions vides et inutiles sur le client. Même lorsque j'ai défini un gestionnaire d'erreur personnalisé, je n'ai pas été en mesure d'obtenir des traces de pile de bas niveau ! Terrible.
• Quelques bogues mineurs dans le support IDE et ailleurs. J'ai déposé deux demandes de bug qui ont été acceptées. Il n'a pas fallu un Einstein pour comprendre qu'il s'agissait en fait de bogues.
• LA DOCUMENTATION EST NULLE. Comme je l'ai mentionné, les proxies devraient être mieux expliqués, le terme est MISLEADING. Pour les problèmes communs de base, que j'ai résolus, la documentation est inutile. Un autre exemple de mauvaise compréhension du DOC est la connexion des annotations JPA à RF. D'après la documentation succincte, il semble qu'ils jouent en quelque sorte ensemble, et oui, il y a une question correspondante sur StackOverflow. Je recommande d'oublier toute "connexion" JPA avant de comprendre RF.

Avantages de RequestFactory

• Excellent support du forum.
• Le support IDE est assez bon (mais n'est pas un avantage par rapport à RPC).
• Flexibilité de l'implémentation de votre client et de votre serveur (couplage lâche)
• Trucs fantaisistes, liés aux EntityProxies, au-delà des simples DTO - mise en cache, mises à jour partielles, très utiles pour le mobile.
• Vous pouvez utiliser les ValueProxies comme remplacement le plus simple des DTO (mais vous devez faire toutes les conversions moins sophistiquées vous-même).
• Support pour les validations de haricots JSR-303.

Considérant d'autres inconvénients de GWT en général :

• Impossible d'exécuter des tests d'intégration (code client GWT + serveur distant) avec le support JUnit fourni <= tous les JSNI doivent être simulés (par exemple localStorage), SOP est un problème.

• Pas de support pour la configuration des tests - navigateur sans tête + serveur distant <= pas de tests simples sans tête pour GWT, SOP.

• Oui, il est possible d'exécuter des tests d'intégration Selenium (mais ce n'est pas ce que je veux).

• JSNI est très puissant, mais dans les discours brillants qu'ils donnent lors des conférences, ils ne parlent pas beaucoup du fait que l'écriture des codes JSNI a aussi quelques règles. Encore une fois, comprendre comment écrire un simple callback était une tâche digne d'un vrai chercheur.

En résumé, la transition de GWT RPC à RequestFactory est loin d'être une situation WIN-WIN, quand RPC correspond principalement à vos besoins. Vous finissez par écrire des tonnes de conversions d'objets du domaine client en proxies et vice-versa. Mais vous obtenez une certaine flexibilité et robustesse de votre solution. Et le support sur le forum est excellent, y compris le samedi !

Compte tenu de tous les avantages et inconvénients que je viens de mentionner, il est vraiment utile de réfléchir à l'avance si l'une de ces approches apporte réellement une amélioration à votre solution et à votre configuration de développement sans grands compromis.

Answer 3

Je trouve l'idée de créer des classes Proxy pour toutes mes entités assez ennuyeuse. Mes pojos Hibernate/JPA sont générés automatiquement à partir du modèle de la base de données. Pourquoi dois-je maintenant créer un second miroir de ceux-ci pour le RPC ? Nous disposons d'un joli cadre d'"estivation" qui se charge de "désinhiber" les pojos.

De même, l'idée de définir des interfaces de service qui n'implémentent pas tout à fait le service côté serveur comme un contrat Java, mais qui implémentent les méthodes, me semble très J2EE 1.x/2.x.

Answer 4

Contrairement à RequestFactory qui a une mauvaise gestion des erreurs et des capacités de test (puisqu'il traite la plupart des choses sous le capot de GWT), RPC vous permet d'utiliser une approche plus orientée service. RequestFactory met en œuvre une approche plus moderne de style injection de dépendance qui peut fournir une approche utile si vous avez besoin d'invoquer 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 mise en forme 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 le cite la section gwt dev du site Web de Google.

"Déploiement simple client/serveur

La première et la plus simple façon d'envisager les définitions de service est de les considérer comme l'ensemble du back-end de votre application. Dans cette perspective, le code côté client est votre "front-end" et tout le code de service qui s'exécute sur le serveur est le "back-end". Si vous adoptez cette approche, vos implémentations de services auront tendance à être des API plus générales qui ne sont pas étroitement liées à une application spécifique. Vos définitions de services sont susceptibles d'accéder directement aux bases de données via JDBC ou Hibernate, voire aux fichiers du système de fichiers du serveur. Ce point de vue est approprié pour de nombreuses applications et peut être très efficace car il réduit le nombre de niveaux.

Déploiement multi-niveaux

Dans des architectures plus complexes, à plusieurs niveaux, vos définitions de services GWT pourraient simplement être des passerelles légères qui appellent à travers des environnements de serveurs back-end tels que les 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 polyvalents, les services sont créés pour répondre aux besoins spécifiques de votre interface utilisateur. Vos services deviennent le "front-end" des classes "back-end" qui sont écrites en assemblant des appels à une couche de services back-end plus générale, mise en œuvre, par exemple, comme 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 la création d'environ 6 classes java, alors que RPC n'en nécessite que 3. Plus de code == plus d'erreurs et de complexité dans mon livre.

RequestFactory a également un peu plus de frais généraux pendant le traitement de la demande, car il doit mettre en forme la sérialisation entre les proxies de données et les modèles java réels. Cette interface supplémentaire ajoute des cycles de traitement supplémentaires qui peuvent vraiment s'accumuler dans une entreprise ou un environnement de production.

Je ne pense pas non plus que les services RequestFactory soient des services de sérialisation comme les services RPC.

Dans l'ensemble, après avoir utilisé les deux depuis un certain temps maintenant, j'ai toujours opté pour 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é ajoutée ne fait pas de lui un meilleur outil nécessaire.

Je pense que la meilleure architecture est d'utiliser deux applications web, un client et un serveur. Le serveur est une simple application web java générique et légère qui utilise la bibliothèque servlet.jar. Le client est GWT. Vous faites une demande RESTful via GWT-RPC dans le côté serveur de l'application web du client. Le côté serveur du client est juste un passage vers le client apache http qui utilise un tunnel persistant dans le gestionnaire de demande que vous avez exécuté comme un seul servlet dans votre application web servlet serveur. L'application web servlet doit contenir votre couche d'application de base de données (hibernate, cayenne, sql, etc.). Cela vous permet de divorcer complètement les modèles d'objets de base de données du client actuel, ce qui fournit un moyen beaucoup plus extensible et robuste de développer et de tester votre application. D'accord, cela nécessite un peu de temps de configuration initiale, mais à la fin, cela vous permet de créer une usine de requête dynamique en dehors de GWT. Cela vous permet de tirer parti du meilleur des deux mondes. Sans parler de la possibilité de tester et d'apporter des changements à votre côté serveur sans avoir à compiler ou construire le client GWT.

Answer 5

Je pense que c'est vraiment utile si vous avez un pojo lourd du côté client, par exemple si vous utilisez des entités Hibernate ou JPA. Nous avons adopté une autre solution, en utilisant un cadre de persistance de style Django avec des entités très légères.