Quand utilisez-vous une JSP et quand une servlet?
J'ai une application qui envoie le client sur un autre site pour gérer les paiements. L'autre site, en dehors du client, appelle une page sur notre serveur pour nous informer de l'état du paiement. La page appelée vérifie les paramètres fournis par l'application de paiement et vérifie si la transaction nous est connue. Il met ensuite à jour la base de données pour refléter le statut. Tout cela se fait sans aucune interaction avec le client.
J'ai personnellement choisi d'implémenter cette fonctionnalité en tant que JSP car il est plus facile de simplement déposer un fichier dans le système de fichiers que de le compiler et de le conditionner, puis d'ajouter une entrée dans un fichier de configuration.
Compte tenu de la fonctionnalité de la page, je présumerais qu'une servlet serait l'option préférée. Les questions sont les suivantes:
Une JSP est compilée dans un servlet lors de sa première exécution. Cela signifie qu'il n'y a pas de réelle différence d'exécution entre eux.
Cependant, la plupart ont l'habitude d'utiliser des servlets pour les contrôleurs et des JSP pour les vues. Comme les contrôleurs ne sont que des classes Java, vous pouvez obtenir un support complet des outils (complétion de code, etc.) de tous les IDE. Cela donne une meilleure qualité et des temps de développement plus rapides par rapport aux JSP. Certains IDE plus avancés (comme IntelliJ IDEA) ont un excellent support JSP, rendant cet argument obsolète.
Si vous créez votre propre framework ou utilisez simplement de simples JSP, vous devriez vous sentir libre de continuer à utiliser les JSP. Il n'y a pas de différence de performances et si vous pensez que les JSP sont plus faciles à écrire, continuez.
JSP: pour présenter des données à l'utilisateur. Aucune logique métier ne devrait exister, et certainement aucun accès à une base de données.
Servlets: Pour gérer les entrées d'un formulaire ou d'une URL spécifique. Habituellement, les utilisateurs utiliseront une bibliothèque telle que Struts/Spring au-dessus de Servlets pour clarifier la programmation. Indépendamment de cela, la servlet doit simplement valider les données entrantes, puis les transmettre à une implémentation de la couche de gestion dorsale (sur laquelle vous pouvez coder des scénarios de test). Il convient ensuite de placer les valeurs résultantes sur la demande ou la session et d'appeler un JSP pour les afficher.
Modèle: un modèle de données contenant vos données structurées gérées par le site Web. La servlet peut prendre les arguments, les insérer dans le modèle, puis appeler la couche de gestion. Le modèle peut alors s’interfacer avec les DAO (ou Hibernate) d’arrière-plan pour accéder à la base de données.
Tout projet non trivial doit implémenter une structure MVC. Il va sans dire qu’il est excessif pour des fonctionnalités triviales. Dans votre cas, je mettrais en œuvre un servlet qui a appelé un DAO pour mettre à jour le statut, etc., ou ce qui est requis.
Les JSP doivent être utilisés dans la couche de présentation, les servlets pour la logique métier et le code back-end (généralement la couche base de données).
Je ne connais aucune raison pour laquelle vous ne pouvez pas utiliser un fichier JSP tel que vous le décrivez (il est de toute façon compilé en servlet par le conteneur), mais vous avez raison, la méthode recommandée consiste à en faire un servlet au départ .
Les JSP sont un raccourci pour écrire une servlet. En fait, ils sont traduits en code Java de servlet avant la compilation. (Vous pouvez le vérifier sous un sous-répertoire Tomcat dont je ne me souviens pas du nom).
Pour choisir entre un servlet et un JSP, j'utilise une règle simple: si la page contient plus de code HTML que de code Java, choisissez JSP, sinon écrivez simplement un servlet. En général, cela se traduit approximativement par: utiliser les JSP pour la présentation du contenu et les servlets pour le contrôle, la validation, etc.
En outre, il est plus facile d'organiser et de structurer votre code à l'intérieur d'un servlet, car il utilise la syntaxe de classe Java. Les JSP ont tendance à être plus monolithiques, bien qu'il soit possible de créer des méthodes à l'intérieur.
Il y a 2 règles assez simples:
- Chaque fois que vous voulez écrire du code Java (logique métier), faites-le dans une classe Java (so Servlet).
- Chaque fois que vous souhaitez écrire du code HTML/CSS/JS (logique d'affichage/modèle), faites-le dans un fichier JSP.
Question connexe:
Je sais que ce n'est pas la réponse populaire aujourd'hui, mais: lorsque je conçois une application à partir de rien, j'utilise toujours des JSP. Lorsque la logique n’est pas triviale, je crée des classes Java ordinaires pour effectuer le travail sommaire que j’appelle à partir du JSP. Je n'ai jamais compris l'argument selon lequel vous devriez utiliser des servlets car, en tant que classes Java pures, elles sont plus faciles à gérer. Un JSP peut facilement appeler une classe Java pure. Bien entendu, une classe Java ordinaire est aussi facile à gérer que n'importe quel servlet. Il est plus facile de formater une page dans un fichier JSP, car vous pouvez mettre tout le balisage en ligne au lieu de devoir écrire un tas de println. Mais le principal avantage des JSP est que vous pouvez simplement les déposer dans un répertoire et qu'ils sont directement accessibles: vous n'avez pas à vous soucier de la configuration des relations entre l'URL et le fichier de classe. La sécurité est facilement gérée en commençant chaque vérification par un fichier JSP par une vérification de sécurité, qui peut consister en une instruction d'appel unique. Il n'est donc pas nécessaire de placer la sécurité dans une couche de répartition.
La seule raison pour laquelle je peux voir utiliser un servlet est si vous avez besoin d'un mappage complexe entre les URL et la classe d'exécution résultante. Par exemple, si vous souhaitez examiner l'URL, puis appeler l'une des nombreuses classes en fonction de l'état de la session ou d'une autre. Personnellement, je n'ai jamais voulu faire cela, et les applications que j'ai vues le font ont tendance à être difficiles à maintenir car avant de pouvoir commencer à effectuer un changement, vous devez déterminer quel code est réellement exécuté.
Les JSP sont essentiellement des balises qui sont automatiquement compilées en servlet par le conteneur de servlets, de sorte que l'étape de compilation se produira dans les deux cas. C'est pourquoi un conteneur de servlets prenant en charge JSP doit disposer de l'ensemble du JDK, par opposition à l'utilisation du JRE.
La raison principale de JSP est donc de réduire la quantité de code nécessaire pour rendre une page. Si vous n'avez pas à rendre une page, une servlet est préférable.
D'accord avec tous les points ci-dessus sur les différences entre les JSP et les servlets, mais voici quelques considérations supplémentaires. Vous écrivez:
J'ai une application qui envoie le client sur un autre site pour gérer le fichier Paiements. L'autre site, en dehors de le client, appelle une page sur notre serveur pour nous faire savoir quel est le statut est du paiement. La page appelée vérifie les paramètres donnés par l'application de paiement et les chèques pour voir si la transaction est connu de nous. Il met ensuite à jour le fichier base de données pour refléter le statut. Ce est tout fait sans aucune interaction avec le client.
Votre application utilise le service de paiement d'une autre application. Votre solution est fragile, car si le service de paiement de l’autre application change, la page JSP s’éclate. Ou si vous souhaitez modifier les règles de paiement de votre application, votre page devra être modifiée. La réponse courte est que votre application devrait utiliser le service de paiement de l'application via un service Web. Ni une servlet ni une page JSP ne sont un endroit approprié pour mettre votre logique de consommation.
Deuxièmement, dans cet ordre d'idées, la plupart des utilisations de pages de servlets/JSP au cours des dernières années ont été placées dans le contexte d'un cadre tel que Spring ou Struts. Je recommanderais Spring, car il vous offre la pile complète de ce dont vous avez besoin, des pages de serveur à la logique de passerelle de service Web destinée aux DAO. Si vous voulez comprendre les rouages du printemps, je recommanderais Spring in Action . Si vous avez besoin de mieux comprendre comment hiérarchiser une architecture d'entreprise écrite dans un langage tel que Java (ou C #), je vous recommanderais Patterns of Enterprise Application Architecture .
De nos jours, la plupart des applications Java reposent sur le modèle MVC ... Du côté du contrôleur (servlet), vous implémentez la logique métier. Le contrôleur de servlet transfère généralement la demande à un jsp qui générera la réponse HTML réelle (la vue dans MVC) . Le but est de séparer les préoccupations ... Des milliers de livres ont été écrits sur ce sujet.
Dans une architecture MVC, les servlets sont utilisés en tant que contrôleur et les JSP en tant que vues . Mais les deux sont techniquement identiques. JSP sera traduit en servlet, soit au moment de la compilation (comme dans JDeveloper), soit lors du premier accès (comme dans Tomcat) . La vraie différence réside donc dans la facilité d'utilisation. Je suis sûr que vous aurez du mal à rendre une page HTML à l'aide de servlet; mais contrairement au sens commun, vous trouverez en fait assez facile de coder même une logique assez complexe dans JSP (avec l’aide d’une classe d’aide préparée, par exemple). PHP les gars le font tout le temps. Et ainsi, ils tombent dans le piège de la création de codes spaghettis… Donc ma solution à votre problème: si vous trouvez qu'il est plus facile de coder dans JSP et que cela ne nécessite pas trop de code, n'hésitez pas à coder dans JSP. Sinon, utilisez servlet.
je pense que c'est à vous de jouer? Parce que JSP est Java à l'intérieur de HTML et Servlet est un Java qui peut faire le HTML à l'intérieur
hmmm ... servlet est plus sercure que jsp car si vous soumettez à Servlet et transmettez-le à un autre JSP, aucune extension de fichier n'apparaît et vous ne pouvez pas voir de quelle page il s'agit ..
mais l’avantage de JSP est que vous pouvez y coder facilement.
Dans le servlet Java, les balises HTML sont intégrées au codage Java . En JSP, les codages Java sont incorporés dans des balises HTML.
Pour les grosses applications et les gros problèmes, le servlet est complexe à lire, à comprendre, à déboguer, etc. en raison de l’illisibilité d’incorporer plus de balises HTML dans le codage Java.
Merci et salutations, Sivakumar.j
Oui, cela devrait être une servlet. Un JSP peut être plus facile à développer, mais un servlet sera plus facile à maintenir. Imaginez juste avoir à corriger un bogue aléatoire en 6 mois et à essayer de vous rappeler comment cela fonctionnait.