Partie 2. Parlons un peu de l'architecture logicielle

Ce matériel fait partie de la série « Introduction au développement d'entreprise ». La première partie sur le réseau est ici . L'architecture logicielle est la structure sur la base de laquelle une application est créée et les modules et composants de l'ensemble du programme interagissent. Les programmeurs tentent de créer une bonne architecture depuis très longtemps. Il n’est donc pas surprenant que nous connaissions désormais de nombreux modèles architecturaux. Vous devez les comprendre : lorsque vous écrivez une application Web, le problème de l'architecture devient aigu, car elle contient plus de composants et de modules que dans une application classique. Un modèle architectural est une manière déjà réfléchie de résoudre un problème de conception logicielle. Vous avez probablement déjà rencontré des modèles de conception tels que Factory Method, Abstract Factory, Builder, Prototype, Singleton et peut-être d'autres. Ils sont utilisés simplement pour écrire du code, créer des classes et planifier leur interaction. Les modèles architecturaux sont utilisés à un niveau d'abstraction plus élevé - lors de la planification de l'interaction de l'utilisateur de l'application avec le serveur, les données et d'autres composants du projet. Jetons un coup d'œil rapide à quelques modèles et à la manière de les utiliser.

Architecture client-serveur

D'après le nom, on a l'impression que tout sur ce sujet est simple et clair. Mais clarifions quelques points pour que lorsque vous commencerez à étudier le Printemps conditionnel, vous compreniez exactement de quoi nous parlons. Disons que vous avez écrit une conversation et que vous et votre ami commencez à l'utiliser. Une option simple est possible ici : vous vous envoyez un message directement via Internet en utilisant des adresses IP que vous connaissez : Au début, il peut sembler que tout fonctionne bien, jusqu'à ce qu'un autre de vos amis apparaisse avec la question : « Pourquoi ne tu ne m'ajoutes pas à ton chat ? Et lorsque vous décidez d'ajouter un ami commun au chat, vous êtes confronté à un problème architectural : chaque utilisateur du chat doit mettre à jour les informations sur le nombre d'utilisateurs, ajouter l'adresse IP du nouvel utilisateur. Et lors de l'envoi d'un message, il doit être transmis à tous les participants. Ce sont les problèmes les plus évidents qui se poseront. Beaucoup plus de problèmes seront cachés dans le code lui-même. Pour les éviter, vous devez utiliser un serveur qui stockera toutes les informations sur les utilisateurs et connaîtra leurs adresses. Le message devra uniquement être envoyé au serveur. Et lui, à son tour, enverra le message à tous les destinataires. Lorsque vous décidez d'ajouter un côté serveur à votre discussion, vous commencerez à construire une architecture client-serveur.

Composants de l'architecture client-serveur

Voyons ce qu'elle est. L'architecture client-serveur est un modèle de conception, base de la création d'applications Web. Cette architecture se compose de trois composants :

1. Client - d'après le nom, il apparaît clairement qu'il s'agit d'un utilisateur d'un service (application Web) qui contacte le serveur pour obtenir des informations.

2. Le serveur est l'endroit où se trouve votre application Web ou sa partie serveur. Il possède les informations nécessaires sur les utilisateurs ou peut les demander. De plus, lorsqu'un client contacte, le serveur renvoie les informations demandées.

3. Le réseau est simple : il assure l'échange d'informations entre le client et le serveur.

Le serveur peut traiter un grand nombre de requêtes provenant de différents utilisateurs. Autrement dit, il peut y avoir de nombreux clients et s'ils doivent échanger des informations entre eux, cela devra se faire via le serveur. Ainsi, le serveur reçoit une fonction supplémentaire supplémentaire : le contrôle du trafic. Si nous parlons du chat multi-utilisateurs que nous avons créé, l'ensemble du code du programme sera composé de deux modules :

• client - contient une interface graphique pour l'autorisation, l'envoi/réception de messages ;

• côté serveur : une application Web hébergée sur un serveur et qui reçoit les messages des utilisateurs, les traite, puis les envoie aux destinataires.

Lorsque nous souhaitons consulter des informations utiles (ou moins utiles) sur Internet, nous ouvrons un navigateur, saisissons une requête dans la barre de recherche et, en réponse, nous recevons des informations du moteur de recherche. Dans cette chaîne, le navigateur est notre client. Il envoie une requête contenant des informations sur ce que nous recherchons au serveur. Le serveur traite la requête, trouve les résultats les plus pertinents, les regroupe dans un format compréhensible pour le navigateur (client) et les renvoie. Dans des services aussi complexes que les moteurs de recherche, il peut y avoir de nombreux serveurs. Par exemple, un serveur d'autorisation, un serveur de recherche d'informations, un serveur de génération de réponse. Mais le client n’en sait rien : pour lui, le serveur est quelque chose d’unifié. Le client connaît uniquement le point d'entrée, c'est-à-dire l'adresse du serveur auquel il doit envoyer la requête. Rappelons-nous l'application que nous avons examinée dans la partie précédente : pour surveiller en temps réel la température moyenne de l'air dans tous les pays. Son architecture ressemblera à ceci : Notre application est située sur un serveur. Disons que toutes les cinq secondes, il envoie des requêtes aux serveurs des centres hydrométéorologiques locaux, en reçoit des informations sur la température dans un pays particulier et stocke ces informations. Lorsqu'un client nous contacte pour nous demander de « voir la température actuelle de l'air dans le monde », nous renvoyons les dernières informations stockées, triées par pays. Ainsi, notre application est à la fois un serveur (lorsqu'elle traite les requêtes des utilisateurs) et un client (lorsqu'elle reçoit des informations d'autres serveurs). Une architecture client-serveur simple est très rarement utilisée et uniquement pour des applications très simples. Pour les projets très vastes et complexes, différents types d'architectures sont utilisés, avec lesquels vous vous familiariserez davantage à l'avenir. Pour l'instant, regardons un modèle très similaire à un modèle client-serveur.

Architecture à trois niveaux

Il s'agit d'un modèle architectural qui introduit un troisième acteur : l'entrepôt de données . Lorsque vous utilisez ce modèle, les trois niveaux sont généralement appelés calques :

1. La couche client est l'interface utilisateur. Il peut s'agir d'un navigateur Web vers lequel les pages HTML sont envoyées ou d'une application GUI écrite à l'aide de JavaFX. L'essentiel est qu'avec son aide, l'utilisateur puisse envoyer des requêtes au serveur et traiter ses réponses.

2. La couche logique est le serveur sur lequel les requêtes/réponses sont traitées. On l’appelle souvent aussi couche serveur. Toutes les opérations logiques ont également lieu ici : calculs mathématiques, opérations sur les données, appels à d'autres services ou stockage de données.

3. La couche de données est le serveur de base de données : notre serveur y accède. Cette couche stocke toutes les informations nécessaires que l'application utilise pendant le fonctionnement.

Ainsi, notre serveur assume toutes les obligations d'accès aux données, sans permettre à l'utilisateur d'y accéder directement.

Avantages d'une architecture à trois niveaux

En utilisant une telle architecture, nous obtenons de nombreux avantages, notamment :

1. La possibilité de créer une protection contre les injections SQL est une attaque contre le serveur dans lequel le code SQL est transmis, et lorsque ce code est exécuté, l'attaquant peut affecter notre base de données.

2. Délimitation des données auxquelles nous souhaitons réguler l'accès des utilisateurs.

3. Possibilité de modifier les données avant de les envoyer au client.

4. Évolutivité - la possibilité d'étendre notre application sur plusieurs serveurs qui utiliseront la même base de données.

5. Moins d'exigences sur la qualité de la connexion de l'utilisateur. Lors de la génération d'une réponse sur le serveur, nous prenons souvent de nombreuses informations différentes de la base de données, les formatons, ne laissant que ce dont l'utilisateur a besoin. De cette façon, nous réduisons la quantité d'informations que nous envoyons en réponse au client.

À quelle fréquence devez-vous utiliser des modèles architecturaux ?

Si vous connaissez, par exemple, le modèle de conception Factory Method , vous vous êtes probablement demandé quand l'utiliser. Parfois, il est difficile de décider quoi faire : créer un objet en utilisant l'opérateur new ou en utilisant une méthode de fabrique. Mais avec le temps, la compréhension vient. Avec les modèles architecturaux, les choses sont un peu différentes. Les frameworks d'entreprise sont conçus pour que le programmeur puisse les utiliser pour créer un projet basé sur un modèle généralement accepté. Par conséquent, avant d'apprendre Spring Framework, vous devez absolument comprendre ce que sont l'architecture client-serveur, l'architecture à trois niveaux et l'architecture MVC. Ne vous inquiétez pas : nous parlerons de l'architecture MVC plus tard. Partie 1. Ce que vous devez savoir avant d'apprendre Spring et JavaEE Partie 3. Protocoles HTTP/HTTPS Partie 4. Bases de Maven Partie 5. Servlets. Écrire une application Web simple Partie 6. Conteneurs de servlets Partie 7. Présentation du modèle MVC (Model-View-Controller) Partie 8. Écrire une petite application Spring-boot