CodeGym/Blog Java/Random-FR/Spring for lazy people Foundation, concepts de base et ex...
John Squirrels
Niveau 41
San Francisco

Spring for lazy people Foundation, concepts de base et exemples avec code. Partie 1

Publié dans le groupe Random-FR
membres
Spring for lazy people Foundation, concepts de base et exemples avec code.  Partie 1 - 1Dans cet article, je ne vais pas vous dire comment mettre en place un projet Spring fonctionnel en 5 minutes en utilisant mon code. Je vais seulement écrire les bases - des choses que vous pourriez ignorer et créer encore un projet. Mais dans cet article, vous ne comprendrez toujours pas ce qui se passe et, plus important encore, pourquoi.

Qu'est-ce que le Spring Framework ?

Le Spring Framework, ou simplement Spring, est l'un des frameworks les plus populaires pour créer des applications Web en Java. Un framework est comme une bibliothèque (vous êtes peut-être plus familier avec ce terme), mais il y a quelque chose à considérer. En gros, lorsque vous utilisez une bibliothèque, vous créez simplement des instances des classes qu'elle contient, appelez les méthodes dont vous avez besoin et obtenez ainsi le résultat dont vous avez besoin. En d'autres termes, il s'agit d'une approche plus impérative : dans votre programme, vous indiquez explicitement le moment précis où vous devez créer quel objet, quand appeler quelle méthode spécifique, etc. Avec les frameworks, les choses sont légèrement différentes. Vous écrivez simplement vos propres classes et y écrivez de la logique, mais ensuite le framework lui-même crée des instances de vos classes et appelle leurs méthodes. Vos classes implémentent généralement certaines interfaces du framework ou héritent de certaines de ses classes, vous fournissant ainsi certaines fonctionnalités qui ont déjà été écrites pour vous. Mais ce n'est pas toujours le cas. Par exemple, Spring essaie autant que possible d'éviter un tel couplage étroit (où vos classes dépendent directement des classes/interfaces du framework). Il utilise des annotations pour y parvenir. Nous y reviendrons plus tard. Mais il est important de comprendre que Spring n'est qu'une collection de classes et d'interfaces que vous pouvez utiliser :) Je tiens également à noter tout de suite que Spring peut être utilisé non seulement pour les applications Web, mais également pour les programmes de console les plus courants. qui nous sont si familiers à tous. Et nous en écrirons même un aujourd'hui. vous fournissant ainsi certaines fonctionnalités qui ont déjà été écrites pour vous. Mais ce n'est pas toujours le cas. Par exemple, Spring essaie autant que possible d'éviter un tel couplage étroit (où vos classes dépendent directement des classes/interfaces du framework). Il utilise des annotations pour y parvenir. Nous y reviendrons plus tard. Mais il est important de comprendre que Spring n'est qu'une collection de classes et d'interfaces que vous pouvez utiliser :) Je tiens également à noter tout de suite que Spring peut être utilisé non seulement pour les applications Web, mais également pour les programmes de console les plus courants. qui nous sont si familiers à tous. Et nous en écrirons même un aujourd'hui. vous fournissant ainsi certaines fonctionnalités qui ont déjà été écrites pour vous. Mais ce n'est pas toujours le cas. Par exemple, Spring essaie autant que possible d'éviter un tel couplage étroit (où vos classes dépendent directement des classes/interfaces du framework). Il utilise des annotations pour y parvenir. Nous y reviendrons plus tard. Mais il est important de comprendre que Spring n'est qu'une collection de classes et d'interfaces que vous pouvez utiliser :) Je tiens également à noter tout de suite que Spring peut être utilisé non seulement pour les applications Web, mais également pour les programmes de console les plus courants. qui nous sont si familiers à tous. Et nous en écrirons même un aujourd'hui. Spring essaie autant que possible d'éviter un tel couplage étroit (où vos classes dépendent directement des classes/interfaces du framework). Il utilise des annotations pour y parvenir. Nous y reviendrons plus tard. Mais il est important de comprendre que Spring n'est qu'une collection de classes et d'interfaces que vous pouvez utiliser :) Je tiens également à noter tout de suite que Spring peut être utilisé non seulement pour les applications Web, mais également pour les programmes de console les plus courants. qui nous sont si familiers à tous. Et nous en écrirons même un aujourd'hui. Spring essaie autant que possible d'éviter un tel couplage étroit (où vos classes dépendent directement des classes/interfaces du framework). Il utilise des annotations pour y parvenir. Nous y reviendrons plus tard. Mais il est important de comprendre que Spring n'est qu'une collection de classes et d'interfaces que vous pouvez utiliser :) Je tiens également à noter tout de suite que Spring peut être utilisé non seulement pour les applications Web, mais également pour les programmes de console les plus courants. qui nous sont si familiers à tous. Et nous en écrirons même un aujourd'hui. ) Je tiens également à noter tout de suite que Spring peut être utilisé non seulement pour les applications Web, mais également pour les programmes de console les plus courants qui nous sont tous si familiers. Et nous en écrirons même un aujourd'hui. ) Je tiens également à noter tout de suite que Spring peut être utilisé non seulement pour les applications Web, mais également pour les programmes de console les plus courants qui nous sont tous si familiers. Et nous en écrirons même un aujourd'hui.

Structure

Mais Spring n'est pas qu'un framework en particulier. Il s'agit plutôt d'un nom commun utilisé pour désigner plusieurs petits frameworks, chacun effectuant son propre type de travail. Spring for lazy people Foundation, concepts de base et exemples avec code.  Partie 1 - 2

https://docs.spring.io/spring/docs/4.3.26.RELEASE/spring-framework-reference/htmlsingle/
Figure 2.1. Présentation du framework Spring

Comme vous pouvez le voir, Spring est modulaire. Cela nous permet de connecter uniquement les modules dont nous avons besoin pour notre application et de ne pas connecter ceux que nous n'utiliserons évidemment pas. Autant que je sache, c'est cette approche qui a permis à Spring de surpasser son concurrent de l'époque (EJB) et de prendre les devants. Les applications utilisant EJB traînaient beaucoup de dépendances derrière elles et, par conséquent, elles se sont avérées lentes et lentes. L'image montre que Spring Framework se compose de plusieurs modules :
  • Accès aux données
  • la toile
  • Cœur
  • et plus
Aujourd'hui, nous allons nous familiariser avec certains concepts du module principal : les beans, le contexte et autres. Comme vous l'avez peut-être deviné, le module Data Access contient des outils pour travailler avec des données (principalement des bases de données), et le module Web est pour travailler sur un réseau (y compris la création d'applications Web, qui seront abordées plus tard). De plus, il existe une infrastructure complète qui prend en charge Spring : de nombreux autres projets qui ne sont pas officiellement inclus dans le framework lui-même, mais sont intégrés de manière transparente dans votre projet Spring (par exemple, Spring Security, que j'espère également aborder, est pour l'authentification d'un utilisateur sur un site Web).

Pourquoi Java a-t-il le Spring Framework ?

Eh bien, outre le fait qu'il est à la mode, lisse et frais, je peux dire tout de suite que dès que vous acquérez ne serait-ce qu'une petite quantité de compétences en utilisant Spring, vous comprendrez comment il y a toutes sortes de travaux que vous n'avez plus à faire et combien de travail Spring prend sur lui-même. Vous pouvez écrire quelques dizaines de lignes de paramètres de configuration et écrire quelques classes, et vous vous retrouvez avec un projet fonctionnel. Mais dès que vous commencez à vous demander combien de choses se cachent sous le capot, combien de travail est fait et combien de code vous auriez à écrire si vous deviez implémenter le même projet basé sur des servlets ou des sockets simples et du Java pur, vos cheveux vont se dresser :) Le printemps est même décrit comme une sorte de magie. Vous en faites l'expérience lorsque vous voyez que tout fonctionne, mais vous avez aussi une idée approximative de comment et combien de travail se passe dans les coulisses - il semble donc qu'il y ait vraiment une sorte de magie en action :) Il est plus facile d'appeler cela de la magie que d'essayer d'expliquer comment tout est interconnecté. :) Le deuxième argument en faveur de l'étude de Spring est qu'environ 90 % des offres d'emploi pour les développeurs juniors (d'après mes observations personnelles) nécessitent soit une connaissance, soit au moins une idée générale de ce que propose Spring.Data, Web MVC, et Securityles modules offrent des développeurs sophistiqués :) Mais aujourd'hui, il ne s'agit que des bases.

DI/IoC

Si vous avez déjà essayé de lire sur Spring, la première chose que vous avez rencontrée était probablement ces acronymes : DI/IoC. Maintenant, je vous recommande fortement de faire une pause dans cet article et de lire cet article DZone ! IoC signifie inversion de contrôle. Je l'ai déjà mentionné au passage lorsque j'écrivais qu'utiliser une bibliothèque implique que vous indiquiez vous-même dans votre code quelle méthode appeler sur quel objet, mais qu'utiliser un framework signifie généralement que le framework appellera votre code au bon moment. En d'autres termes, dans ce dernier cas, vous ne gérez plus le processus d'exécution du code/programme — le framework le fait pour vous. Vous avez passé le contrôle au framework (inversion de contrôle). DI signifie injection de dépendance. Avec l'injection de dépendances, vous ne créez pas d'objets cat dans la méthode principale pour ensuite les transmettre à vos méthodes. Au lieu de cela, Spring Framework les crée pour vous. Vous dites simplement quelque chose comme "Je veux avoir un chat ici" et le framework vous en passe un dans votre méthode. Nous verrons cette abréviation dans les prochains articles.

Haricots et contexte

L'un des concepts clés de Spring est un haricot. En fait, ce n'est qu'un objet d'une certaine classe. Supposons que nous ayons un programme qui nécessite 3 objets : un chat, un chien et un perroquet. Et nous avons un tas de classes avec un tas de méthodes. Parfois, nous avons besoin d'un chat pour une méthode, parfois nous avons besoin d'un chien pour une méthode différente, et parfois nos méthodes ont besoin à la fois d'un chat et d'un perroquet (par exemple, la méthode pour nourrir le chat, ha-ha). Pour d'autres méthodes encore, les trois objets sont nécessaires. Oui, nous pourrions d'abord créer ces trois objets dans la méthode main, puis les passer à nos classes, puis au sein de ces classes les passer aux méthodes concernées... Et ainsi de suite tout au long du programme. Mais si nous supposons également que nous voulons occasionnellement modifier la liste des paramètres d'entrée de nos méthodes (par exemple, nous décidons de réécrire quelque chose ou d'ajouter de nouvelles fonctionnalités), nous devrons alors apporter quelques modifications au code. Et maintenant, imaginez que nous n'avons pas 3, mais 300 objets de ce type. Une alternative serait de rassembler tous nos objets dans une liste (List<Object>), passez-le à chaque méthode, puis récupérez l'objet nécessaire à l'intérieur des méthodes. Mais pendant que le programme s'exécute, que se passe-t-il si un objet est ajouté à cette liste, ou pire, que se passe-t-il si un objet est supprimé ? Cela a le potentiel de casser toutes les méthodes où nous utilisons un index pour obtenir des objets de la liste. Pour éviter ce problème, nous décidons de stocker nos objets non pas dans une liste, mais dans une carte, où la clé est le nom de l'objet et la valeur est l'objet lui-même. Cela nous permet de récupérer les objets dont nous avons besoin simplement en utilisant leur nom, par exemple get("parrot"), et en réponse nous obtenons l'objet perroquet. Ou la clé pourrait être la classe de l'objet, et la valeur pourrait être l'objet lui-même. Dans ce cas, plutôt que de spécifier le nom de l'objet, nous pouvons simplement spécifier la classe de l'objet dont nous avons besoin. C'est aussi pratique. Ou nous pourrions même écrire une sorte de wrapper pour la carte, où certaines méthodes obtiennent des objets par leur nom, et d'autres méthodes obtiennent des objets par leur classe. Ce à quoi nous sommes arrivés ici s'appelle uncontexte d'application dans Spring Framework. Un contexte est une collection de beans (objets). Nous accédons à un contexte pour obtenir le bean (objet) dont nous avons besoin par son nom, par son type ou par tout autre moyen. De plus, nous pouvons demander à Spring lui-même d'aller chercher dans son propre contexte le bean dont nous avons besoin et de le transmettre à notre méthode. Par exemple, supposons que nous ayons une méthode comme celle-ci :
public void doSomething(Cat cat) {
    ...
}
Lorsque Spring a appelé cette méthode, il a pris notre objet cat de son contexte et l'a passé à la méthode. Mais maintenant, nous avons décidé qu'en plus d'un chat, notre méthode a également besoin d'un perroquet. Avec Spring, rien de plus simple ! Nous écrivons simplement :
public void doSomething(Cat cat, Parrot parrot) {
    ...
}
Maintenant, lorsque Spring appelle notre méthode, il comprend la nécessité de passer un chat et un perroquet, il va donc dans son contexte, récupère ces deux objets et les passe à notre méthode. En transférant les rênes du contrôle à Spring, nous transférons également la responsabilité de créer des objets et de les transmettre à nos méthodes, que Spring appellera. Cela soulève la question suivante : comment Spring sait-il quels objets (beans) créer ?

Façons de configurer une application

Il existe trois manières principales de configurer une application , c'est-à-dire des manières de dire à Spring exactement quels objets nous avons besoin :
  1. Fichiers de configuration XML
  2. Configuration basée sur Java
  3. configuration automatique
Les créateurs de Spring les classent par ordre de priorité :
  • la méthode prioritaire qu'il convient de privilégier est la configuration automatique
  • si la configuration automatique ne peut pas être utilisée pour configurer correctement tous les beans possibles, utilisez la configuration basée sur Java (qui implique la création d'objets à l'aide de code Java)
  • et la méthode la moins prioritaire est la méthode à l'ancienne - en utilisant des fichiers de configuration XML.
Spring nous permet également de combiner ces méthodes. Par exemple, laissez Spring configurer tout ce qui peut être configuré automatiquement, utilisez une configuration basée sur Java chaque fois que vous avez besoin de paramètres spéciaux et utilisez XML pour toutes les configurations héritées. Tout cela s'avère assez flexible. Néanmoins, si tout peut être configuré automatiquement, choisissez cette option. Je ne considérerai que la configuration automatique et la configuration basée sur Java. Les configurations XML sont utilisées dans presque tous les exemples de Spring sur Internet. De plus, une fois que vous avez compris comment fonctionne la configuration basée sur Java, vous ne devriez avoir aucun problème à lire un fichier XML qui fait la même chose. La configuration automatique est utilisée lorsque nous devons travailler avec des objets de classes que nous avons écrites. Si la création d'un de nos objets nécessite une logique bien précise, ou si nous ne sommes pas en mesure de créer une classe avec l'annotation nécessaire à la configuration automatique, nous pouvons utiliser une configuration basée sur Java pour faire ce qui doit être fait. Dans leprochaine partie , nous allons créer un projet Maven, connecter quelques-uns des principaux modules Spring et créer nos premiers beans.
Commentaires
  • Populaires
  • Nouveau
  • Anciennes
Tu dois être connecté(e) pour laisser un commentaire
Cette page ne comporte pas encore de commentaires