Question

    

Cette question a déjà une réponse ici:

         

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 suppose qu'un servlet serait l'option préférée. Les questions sont:   

  • Ma présomption est-elle correcte?
  •   
  • Existe-t-il une vraie raison d'utiliser une servlet sur un JSP?
  •   
  • Quelles sont ces raisons?
  • Était-ce utile?

    La solution

    Une JSP est compilée dans une 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 (IntelliJ IDEA me vient à l’esprit) ont un excellent support JSP, rendant cet argument obsolète.

    Si vous créez votre propre cadre ou utilisez simplement de simples JSP, vous devriez vous sentir libre de continuer à les utiliser. Il n'y a pas de différence de performances et si vous pensez que les JSP sont plus faciles à écrire, continuez donc.

    Autres conseils

    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 du servlet doit juste valider les données qui ont été entrées, puis les transmettre à une implémentation de la couche de gestion dorsale (sur laquelle vous pouvez coder des cas de test). Il convient ensuite de placer les valeurs résultantes sur la requête ou la session et d’appeler un JSP pour les afficher.

    Modèle: modèle de données contenant les 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 ensuite s’interfacer avec les DAO (ou Hibernate) principaux pour accéder à la base de données.

    Tout projet non trivial doit implémenter une structure MVC. Il va de soi que l’utilisation de fonctionnalités triviales est excessive. Dans votre cas, je mettrais en œuvre un servlet qui a appelé un DAO pour mettre à jour le statut, etc.

    Les fichiers 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 (le compilateur le compilant de toute façon), mais vous avez raison, la méthode recommandée consiste à en faire un servlet la première place.

    Les JSP sont un raccourci pour écrire un 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, optez pour JSP, sinon écrivez simplement un servlet. En général, cela se traduit approximativement par: utiliser des JSP pour la présentation du contenu et des 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, même s’il est alors possible de créer des méthodes à l’intérieur.

    Il existe 2 règles assez simples:

    1. Chaque fois que vous souhaitez écrire du code Java (logique métier), faites-le dans une classe Java (donc, Servlet).
    2. Chaque fois que vous souhaitez écrire du code HTML / CSS / JS (logique d'affichage / modèle), faites-le dans un fichier JSP.

    Question connexe:

    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 la raison pour laquelle un conteneur de servlets prenant en charge JSP doit disposer du JDK complet au lieu de n’avoir besoin que du JRE.

    La raison principale de JSP est donc de réduire la quantité de code requise pour le rendu d'une page. Si vous n'avez pas à rendre une page, une servlet est préférable.

    Je sais que ce n’est pas la réponse populaire de nos jours, mais que: lorsque je conçois une application à partir de rien, j’utilise toujours des JSP. Lorsque la logique n’est pas anodine, 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 et, 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 définir la sécurité dans une couche d'envoi.

    La seule raison pour laquelle je vois l'utilisation d'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 vu le faire ont tendance à être difficiles à maintenir car avant de pouvoir commencer à apporter des modifications, vous devez déterminer quel code est réellement exécuté.

    De nos jours, la plupart des applications java sont construites 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). L’objectif 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 les mêmes. 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, peut-être). Les gars de PHP le font tout le temps. Et ils tombent dans le piège de la création de codes spaghettis. Donc, ma solution à votre problème: si vous avez trouvé qu'il était plus facile de coder dans JSP et que cela n'impliquait pas trop de code, n'hésitez pas à coder dans JSP. Sinon, utilisez servlet.

    Convenez de tous les points ci-dessus concernant 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 à un autre site pour gérer la   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   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, votre 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 ??de Spring, je vous recommande 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 les Patterns of Enterprise Application Architecture de Fowler.

    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 il fonctionnait.

    Dans le servlet Java, les balises HTML sont intégrées au codage Java.   Dans 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 code java. Donc, nous utilisons jsp.In etc.

    Merci & amp; Cordialement, Sivakumar.j

    Je pense que cela dépend de vous? 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.

    Licencié sous: CC-BY-SA avec attribution
    Non affilié à StackOverflow
    scroll top