Le printemps est pour les paresseux. Fondamentaux, concepts de base et exemples avec code. Partie 1

Beaucoup de gens, après avoir lu mes articles sur la création d'un modèle pour un projet Web et sur la création d'un service Web simple à l'aide de servlets , se sont demandé quand j'écrirais sur Spring. Je ne voulais pas, j'ai proposé de lire un livre (et je dis toujours qu'un livre vaut mieux que 10, voire 100 articles sur Internet). Mais maintenant, j'ai décidé qu'en expliquant la même chose à différentes personnes, je passais plus de temps que si je m'asseyais une fois et écrivais un article, puis que je publiais simplement un lien vers celui-ci. J'écris donc pour le lien)). Dans cet article, je n'écrirai pas comment réaliser un projet fonctionnel au Spring en 5 minutes en suivant mon exemple. Je n'écrirai que sur des choses fondamentales, sans lesquelles il est certainement possible de démarrer un projet, mais ce qui s'y passe et, plus important encore, pourquoi, ne sera pas clair.

Qu’est-ce que le framework Spring ?

Spring Framework , ou simplement Spring , est l'un des frameworks les plus populaires pour créer des applications Web en Java. Un framework est quelque chose de similaire à une bibliothèque (ce terme vous est peut-être plus familier), mais il y a un point. En gros, en utilisant une bibliothèque, vous créez simplement les objets des classes qui s'y trouvent, appelez les méthodes dont vous avez besoin et obtenez ainsi le résultat dont vous avez besoin. Autrement dit, il existe une approche plus impérative : vous indiquez clairement dans votre programme à quel moment précis vous devez créer quel objet, à quel moment vous devez appeler une méthode spécifique, etc. Avec les frameworks, les choses sont légèrement différentes. Vous écrivez simplement certaines de vos propres classes, y écrivez une partie de la logique, et le framework lui-même crée des objets de vos classes et appelle des méthodes pour vous. Le plus souvent, vos classes implémentent certaines interfaces du framework ou en héritent, recevant ainsi certaines des fonctionnalités déjà écrites pour vous. Mais il n’est pas nécessaire qu’il en soit ainsi. Au Spring, par exemple, ils essaient de s'éloigner autant que possible d'un couplage aussi strict (lorsque vos classes dépendent directement de certaines classes/interfaces de ce framework), et utilisent des annotations à cet effet. Nous reviendrons sur ce point plus tard. Mais il est important de comprendre que Spring n'est qu'un ensemble de classes et d'interfaces qui ont déjà été écrites pour vous :) Je tiens également à noter immédiatement que Spring peut être utilisé non seulement pour les applications Web, mais aussi pour la console la plus courante. des applications qui nous sont si familières à tous Et aujourd'hui, nous écrirons même quelque chose comme ça.

Structure

Mais Spring n’est pas un framework spécifique. Il s'agit plutôt d'un nom général désignant un certain nombre de petits frameworks, chacun effectuant un travail différent. Comme vous pouvez le constater, le ressort a une structure 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. Parce que les applications utilisant EJB entraînaient de nombreuses dépendances avec elles, et en général elles se révélaient lentes et maladroites. L'image montre que le framework Spring se compose de plusieurs modules :

• accès aux données ;
• la toile;
• cœur;
• et d'autres.

Aujourd'hui, nous allons nous familiariser avec certains concepts du module principal, tels que : les beans, le contexte et autres. Comme vous pouvez le deviner, le module d'accès aux données contient des outils pour travailler avec des données (principalement des bases de données), Web - pour travailler sur le réseau (y compris pour créer des applications Web, qui seront discutées plus tard). En outre, il existe également ce qu'on appelle l'infrastructure Spring complète : de nombreux autres projets qui ne sont pas officiellement inclus dans le framework lui-même, mais qui sont intégrés de manière transparente dans votre projet Spring (par exemple, la même sécurité Spring pour travailler avec l'autorisation de l'utilisateur sur le site, que, je l'espère, nous ressentirons aussi un jour).

Pourquoi Spring en Java ?

Eh bien, outre le fait qu'il est à la mode, élégant et jeune, je peux immédiatement dire que dès que vous le maîtriserez ne serait-ce qu'un peu, vous comprendrez combien de travail différent vous n'avez plus à faire et combien de printemps prend. Vous pouvez écrire quelques dizaines de lignes de configuration, écrire quelques cours - et vous obtiendrez un projet fonctionnel. Mais dès que vous commencez à réfléchir à tout ce qu'il y a « sous le capot », à la quantité de travail effectué et à la quantité de code qu'il faudrait écrire si vous faisiez le même projet sur des servlets nus ou sur des sockets et du Java pur. - tes cheveux se dressent :) Il existe même une telle expression, comme la "magie" du printemps. C'est à ce moment-là que vous voyez que tout fonctionne, mais que vous estimez approximativement combien de choses doivent se passer là-bas pour que tout fonctionne et comment tout cela fonctionne là-bas - alors il semble que tout cela se passe vraiment grâce à une sorte de magie)) C'est plus facile de appelez tout cela de la magie plutôt que d'essayer d'expliquer comment tout est interconnecté là-bas. souriez data_ web-mvc_ security_ juste les bases.

DI/IoC

Si vous avez essayé de lire quelque chose sur Spring, la première chose que vous avez rencontrée était probablement ces lettres : DI/IoC . Maintenant, je vous recommande fortement de faire une pause dans cet article et de lire cet article sur Habré ! IoC (Inversion of Control) - inversion de contrôle. Je l'ai déjà évoqué en passant lorsque j'écrivais que lorsque vous utilisez une bibliothèque, vous écrivez vous-même dans votre code quelle méthode de quel objet appeler, et dans le cas des frameworks, le plus souvent le framework appellera le code que vous avez écrit à droite moment. Autrement dit, ici, vous ne contrôlez plus le processus d'exécution du code/programme, mais le framework le fait pour vous. Vous lui avez transféré le contrôle (inversion de contrôle). DI est compris comme soit une inversion de dépendance (inversion de dépendance, c'est -à-dire une tentative de ne pas établir de connexions dures entre vos modules/classes, où une classe est directement liée à une autre), ou une injection de dépendance (injection de dépendance, c'est-à-dire lorsque les objets cat ne sont pas créés par vous dans l'ensemble, puis vous les transmettez à vos méthodes, et Spring les crée pour vous, et vous lui dites simplement quelque chose comme "Je veux avoir un chat ici" et il vous le transmet dans votre méthode). Nous rencontrerons plus souvent la seconde dans d’autres articles.

Haricots et contexte

L'un des concepts clés du printemps est le haricot . Essentiellement, c'est juste un objet d'une certaine classe. Disons que pour notre programme nous devons utiliser 3 objets : un chat, un chien et un perroquet. Et nous avons un tas de cours avec un tas de méthodes, où parfois nous avons besoin d'un chat pour une méthode, et d'un chien pour une autre méthode, et parfois nous aurons des méthodes où nous avons besoin d'un chat et d'un perroquet (par exemple, une méthode pour nourrir un chat, hehe), et dans certaines méthodes, les trois objets seront nécessaires. Oui, nous pouvons d'abord créer ces trois objets de manière générale, puis les transmettre à nos classes, et de l'intérieur des classes aux méthodes dont nous avons besoin... Et ainsi de suite tout au long du programme. Et si nous imaginons également que nous souhaitons périodiquement modifier la liste des paramètres acceptés pour nos méthodes (enfin, nous avons décidé de réécrire quelque chose ou d'ajouter des fonctionnalités) - alors nous devrons apporter de nombreuses modifications au code si nous en avons besoin change quelque chose. Et si nous imaginions que nous disposions non pas de 3, mais de 300 objets de ce type ? Une alternative consiste à rassembler tous nos objets de ce type dans une liste commune d'objets ( List<Object> ) et à la transmettre à toutes les méthodes, et à partir de l'intérieur des méthodes, nous obtenons tel ou tel objet dont nous avons besoin. Mais que se passerait-il si nous imaginions qu’au fur et à mesure que le programme progresse, un objet puisse être ajouté à cette liste, ou (pire) supprimé ? Ensuite dans toutes les méthodes où l'on récupère les objets de la liste par leur index, tout peut casser. Ensuite, nous décidons de stocker non pas une liste, mais une carte, où la clé sera le nom de l'objet dont nous avons besoin et la valeur sera l'objet lui-même, et nous pourrons alors en obtenir les objets dont nous avons besoin simplement par leur nom. : get("parrot") et en réponse nous avons reçu un objet perroquet Ou, par exemple, la clé est la classe de l'objet, et la valeur est l'objet lui-même, alors on ne peut plus indiquer le nom de l'objet, mais simplement la classe de l'objet dont nous avons besoin, ce qui est également pratique. Ou même écrire une sorte de wrapper sur la carte, dans lequel vous pouvez créer des méthodes permettant dans certains cas de récupérer des objets par leur nom et dans d'autres cas par classe. C'est ce que nous obtenons du contexte d'application Spring . Un contexte est un ensemble de beans (objets). En ce qui concerne le contexte, nous pouvons obtenir le bean (objet) dont nous avons besoin par son nom, par exemple, ou par son type, ou autre chose. De plus, on peut demander à Spring d'aller chercher le bean dont on a besoin dans son contexte et de le passer à notre méthode. Par exemple, si nous avions une méthode comme celle-ci :

public void doSomething(Cat cat) {
    ...
}

Lorsque Spring a appelé cette méthode pour nous, il lui a transmis l'objet de notre chat de son contexte. Nous décidons maintenant que notre méthode, en plus d'un chat, a également besoin d'un perroquet. Utiliser le printemps, rien de plus simple pour nous ! On écrit simplement :

public void doSomething(Cat cat, Parrot parrot) {
    ...
}

et Spring, lorsqu'il appellera notre méthode, comprendra que nous devons passer ici un chat et un perroquet, aller dans son contexte, récupérer ces deux objets et les transmettre à notre méthode. En remettant les rênes de notre programme à Spring, nous lui avons également transféré la responsabilité de créer des objets et de les transmettre à nos méthodes, qu'il appellera. La question se pose : comment Spring saura-t-il quels objets (bacs) créer ?

Méthodes de configuration des applications

Il existe trois manières principales de configurer une application (c'est-à-dire d'indiquer à Spring quels objets nous devons travailler) :

1. en utilisant des fichiers/configurations XML ;
2. en utilisant des configurations Java ;
3. configuration automatique.

Les développeurs Spring les classent dans cet ordre de priorité :

• la méthode la plus prioritaire à privilégier est la configuration automatique ;
• si en utilisant la configuration automatique, il n'est pas possible de configurer correctement tous les beans possibles, utilisez la configuration Java (création d'objets à l'aide du code Java) ;
• Eh bien, la méthode la moins prioritaire est la méthode à l’ancienne, utilisant des configurations XML.

De plus, Spring permet de combiner ces méthodes. Par exemple, laissez Spring faire tout ce qui peut être configuré automatiquement : lorsque vous devez spécifier certains paramètres spéciaux, faites-le à l'aide de configurations Java et, en outre, vous pouvez connecter certaines configurations héritées au format XML. En général, tout cela peut être fait de manière assez flexible. Mais quand même, si tout peut être fait à l'aide des paramètres automatiques, utilisez-le. Je ne considérerai que la configuration automatique et les configurations Java ; Les configurations XML sont déjà utilisées dans presque tous les exemples Spring sur Internet, et une fois que vous avez compris comment fonctionne la configuration Java, il ne devrait y avoir aucun problème à « lire » un fichier XML qui fait la même chose. La configuration automatique est utilisée lorsque les objets dont nous avons besoin pour travailler sont des objets des classes que nous avons écrites . Si une logique très spécifique est nécessaire pour créer un objet de notre classe, ou si nous n'avons pas la possibilité de marquer une classe avec l'annotation dont nous avons besoin, qui serait récupérée par la configuration automatique, cela peut être fait dans les configurations Java. . Dans la partie suivante, nous allons créer un projet maven, y connecter quelques modules Spring centraux et créer nos premiers beans.