Y a-t-il une raison quelconque d'utiliser le ressort MVC (ou d'autres cadres similaires) en tant que serveur pour GWT RPC? Pour autant que je sache, 99,9% des caractéristiques du printemps ne seront pas utilisées. Pourtant, beaucoup de gens cherchent de meilleurs moyens de les utiliser ensemble.
Quelqu'un pourrait-il s'il vous plaît expliquer, quels sont les avantages de l'utilisation de cadres MVC (sur le serveur) avec GWT, lorsque tout ce dont vous avez besoin sur le côté serveur est la logique commerciale?
4 Réponses :
Je ne vois aucun point général à utiliser le printemps MVC ou une autre bibliothèque d'entreprise Java MVC (comme des jambes de force) avec une couche qui, comme vous l'avez dit - offre uniquement une logique commerciale (et peut donc être conservée aussi petite et propre. aussi possible).
Mais le printemps lui-même est bien plus qu'une couche de framework Web (MVC) et en utilisant l'injection de dépendance ou les caractéristiques d'AOOP ou l'API ORM ou le langage de script Groovy (qui fonctionne bien avec le printemps) peut être un avantage énorme). .
L'injection de dépendance peut être atteinte en utilisant différentes bibliothèques. Par exemple la gueule de poids léger. Jamais utilisé AOP, alors ne sais pas si c'est cool ou non. Orm ... oui, j'ai oublié ça. Peut être un bon point.
Si votre application GWT doit apporter des appels RPC sur le serveur, la couche MVC est toujours pertinente.
Ne vois pas comment je pourrais inclure le MVC classique là-bas correctement. La vue est juste une représentation (XML ou JSON) des données afin que vous n'ayez pas vraiment besoin de tout le matériel HTML / JSP / TagLib. Bien sûr, la séparation du modèle et du contrôleur devrait encore exister.
Il existe des bibliothèques GWT-RPC pour le ressort qui enveloppent automatiquement tout ce dont vous avez besoin au format GWT-RPC. Donc, vous ne nez pas de XML ou JSON.
Eh bien, OK Les données GWT-RPC sont transférées uniquement dans un autre format, mon point de vue que vous pouvez épargner tout le fuzz HTML / JSP que la plupart des frameworks Web Java offrent lors de l'utilisation de GWT-RPC (ou de tout autre format sérialisé).
Le printemps est beaucoup plus que MVC.
Même lorsque vous faites votre interface utilisateur avec GWT, vous avez toujours besoin d'une sorte de logique backend. Des choses comme des bases de données, des transactions, de la sécurité, des intégrations de services supplémentaires (courriels? Savon?) Et ainsi de suite.
Pour ce printemps ou toute autre technologie latérale du serveur Java peut être une bonne solution.
Comme DAFF a dit, Spring apporte DI + AOP + Transactions + Beaucoup de choses ... Il est utile de faire gérer ces trucs sur votre serveur avec le printemps.
En outre, la bibliothèque GWTRPC-Spring offre un moyen très pratique de déclarer Pojos en tant que services RPC, avec l'annotation @service. Il évite la déclaration de chaque servlets RPC dans la web.xml, car la numérisation des classes avec @Service est automatique.
GWT n'est qu'une boîte à outils, pas un cadre. Si le printemps peut faciliter votre devir, utilisez-le simplement.
J'ai tendance à utiliser GWT + Gin sur le côté client et Guice du côté serveur. Mais le printemps pourrait tout simplement être utilisé pour la persistance, les transactions et l'organisation de votre logique commerciale sur le côté serveur.
«99,9% Les caractéristiques du printemps ne seront pas utilisées» ... Que vous avez donné cette impression?
Eh bien, je suppose que je n'ai pas vu tout cela est des usages. Tout ce que j'ai travaillé avec l'utilisation du printemps était de différentes manières d'approche MVC.
Assez juste, mais il y a un lot plus au printemps que MVC.