Structure de l'application Web par Java et flux de traitement dans la couche de présentation

introduction

Lors de la formation des nouveaux employés, nous avons développé une application Web utilisant Java, je voudrais donc résumer brièvement ce que j'ai appris là-bas. Je pense qu'il y a beaucoup d'erreurs, je vous serais donc reconnaissant de bien vouloir le signaler.

Nous nous concentrerons sur le flux de traitement côté serveur de l'application Web. En tant qu'échantillon supposé, il s'agira d'un simple échantillon de recherche à un élément.

Interaction entre les serveurs

Une brève description de l'échange dynamique d'informations entre le client et le serveur lors de la mise en œuvre d'une page Web dynamique.

Tout d'abord, le client envoie une requête au serveur Web. La transmission et la réception entre ce client et le serveur Web sont effectuées par le protocole HTTP. Si vous souhaitez afficher une page Web dynamique, vous devez effectuer un traitement (programme) côté serveur Web. Le processus est une application Web, qui sera implémentée dans des langages côté serveur tels que Java et PHP. Cette fois, il est supposé être implémenté en Java.

Pour exécuter l'application, vous devez disposer d'un serveur d'applications distinct du serveur Web. (Tomcat est célèbre pour les serveurs d'applications Java.) Le serveur d'applications, tout comme l'envoi et la réception entre le client et le serveur Web, nécessite un certain protocole pour envoyer et recevoir vers et depuis l'application Web. Si vous utilisez Tomcat pour le serveur d'applications et Apatch pour le serveur Web comme décrit ci-dessus, implémentez un module de liaison appelé mod_jk dans Apatch en tant qu'extension. Le serveur d'application et le serveur Web peuvent envoyer et recevoir en utilisant le protocole ajp13 de mod_jk. Puisque Tomcat dispose d'un serveur Web simple, il peut envoyer et recevoir sans aucune coopération particulière.

Structure de l'application Web

Voyons maintenant comment l'application Web est traitée de ce côté serveur.

Les applications Web sont conçues avec l'architecture MVC comme modèle et sont grossièrement divisées en trois couches suivantes.

・ Couche de présentation · Affaires ・ Couche d'intégration

Les rôles des programmes contenus dans chaque couche sont clairement séparés.

Ensuite, je décrirai comment le traitement est effectué en fonction des informations de demande du client.

Flux de traitement des applications côté serveur

Les informations de la demande sont d'abord transmises à FrontController. Ce Front Controller est un servlet qui gère de manière centralisée le traitement des applications Web.

Le contrôleur frontal distribue le traitement en fonction des informations de la demande. (L'instruction Switch-case est valide) Action y est appelée, et cette action vérifie la valeur d'entrée, gère la session (crée et libère des objets de session) et demande le traitement à la logique métier de la couche de gestion. (En passant, dans la gestion de session, afin d'utiliser efficacement les ressources du serveur, il est préférable de libérer la session dès que possible, comme la désactivation de la session si l'accès est interrompu pendant un certain temps.)

Et le cœur de métier Logic contrôle le traitement métier. Les informations nécessaires au traitement commercial sont acquises en accédant à la base de données. Utilisez Connection Manager pour accéder à la base de données. Plus précisément, utilisez la méthode getConnection de ConnectionManager pour obtenir l'objet Connection (connexion à la base de données).

Créez un objet DAO en passant cet objet Connection en tant qu'argument au constructeur du DAO. Ensuite, il appelle la méthode DAO et reçoit la valeur de retour à l'aide de Entity.

Comment définir la valeur de retour dans DAO (dans le cas d'une recherche) S'il y a un résultat de recherche avec while (res.next ()), le traitement à l'intérieur de {} est effectué. Dans {}, utilisez res.get ~ pour définir la valeur de retour

Une fois que Business Logic reçoit l'objet Entity, il est stocké dans l'objet défini et défini comme valeur de retour.

Générez une logique métier en action et appelez la méthode. Définissez le résultat dans la portée, etc. Définissez la destination de la page de transition comme valeur de retour.

Dans FrontController, il reçoit la destination de la page de transition d'Action et la transmet.

Comportement de l'application au niveau de la couche de présentation

Servlets et JSP

Un programme appelé servlet est nécessaire pour générer un fichier HTML qui affiche une page Web. Le servlet est exécuté par un serveur d'applications Web tel que Tomcat.

Il est possible d'afficher une page Web avec ce servlet seul, mais comme la description du programme devient compliquée et que ce ne sera pas un beau programme, demandez au JSP avec du code Java intégré en HTML d'afficher la page Web. Sera.

De plus, pour effectuer la transition de la page Web, il est nécessaire d'ajouter des paramètres à la requête envoyée par le client. Il existe deux façons d'envoyer la demande: GET et POST.

OBTENIR et POSTER

Les méthodes GET et POST nécessitent que vous définissiez une valeur en tant que paramètre.

Dans l'opération GET, toute valeur définie dans le paramètre est envoyée au serveur Web sous la forme d'être incorporée dans l'URL. Par conséquent, si vous souhaitez parcourir à nouveau la page Web, vous pouvez facilement y accéder. En d'autres termes, les signets sont enregistrés pour chaque paramètre. Les inconvénients comprennent la limitation de la longueur des paramètres et la faible sécurité comme mentionné ci-dessus.

En revanche, en opération POST, toute valeur définie dans le paramètre n'est pas incluse dans l'URL et est envoyée au serveur Web sous la forme stockée dans le corps du message de la requête. Par conséquent, il est plus sécurisé que l'opération GET. De plus, il n'y a pas de limite à la longueur des paramètres et une grande quantité de données peut être envoyée.

Dans le traitement dans l'application, le servlet défini par l'utilisateur est décrit en remplaçant la méthode doGet et la méthode doPost définies dans HttpServlet. Cela vous permet d'utiliser les fonctionnalités HTTP.

Résumé

Cette fois, j'ai brièvement expliqué le comportement des applications Web côté serveur et le comportement des applications sur la couche présentation. Ce sera plus long que cela, je voudrais donc expliquer la couche métier et la couche d'intégration dans un article séparé.