Préface
En tant que codeur engagé dans le développement de Java, l'importance du printemps est évidente. Vous pouvez faire face aux cadres de printemps tous les jours. Le printemps est tout aussi nommé, apportant un confort de printemps au développement des applications Java. Le printemps peut être considéré comme une base nécessaire pour que tout développeur Java atteigne la technologie avancée. Bien sûr, il n'est pas facile d'apprendre bien le printemps, surtout pour comprendre les principes sous-jacents du printemps. Il faut beaucoup de temps et d'énergie pour l'étudier attentivement, et constamment des essais et des erreurs et résumer dans les projets réels afin de former votre propre réflexion et votre compréhension. Le blogueur avait une compréhension très superficielle du printemps au début, et il était possible de s'appuyer sur le problème que Du Niang pouvait résoudre de manière générale lors de la rencontre avec des problèmes dans le projet. Cependant, depuis plus d'un an depuis que le printemps est en contact avec le printemps, la compréhension de son système de cadre est assez chaotique, et la technologie profonde est toujours comme un brouillard, et elle n'a pas formé sa propre cognition et sa compréhension, ce qui est très défavorable à l'amélioration de la technologie de programmation. Compte tenu de cela, j'ai décidé de me calmer et d'apprendre systématiquement le cadre du printemps du début à la fin, et d'enregistrer les détails d'apprentissage et de partager les connaissances techniques à travers la forme d'un blog. D'accord, passons au point
Introduction au Core Spring Framework
DI (injection de dépendance), injection de dépendance et un autre concept dont nous entendons souvent parler, implémente en fait les mêmes fonctions que le CIO (inversion de contrôle), mais les mêmes fonctions sont expliquées sous différents angles. Le blogueur ici n'ira pas trop analyser, il y a beaucoup d'explications sur Baidu. Ce que nous devons savoir, c'est ce qu'est l'injection de dépendance et pourquoi l'injection de dépendance est. Pour comprendre ces deux points, je pense que l'apprentissage du printemps est le meilleur en termes de réflexion.
Lorsque le printemps n'est pas utilisé - c'est-à-dire lorsqu'il n'y a pas d'injection de dépendance, il est difficile de réaliser une collaboration fonctionnelle mutuelle entre les classes d'applications Java. Si une certaine classe (a) doit implémenter ses fonctions, si elle doit s'appuyer sur la collaboration d'une autre classe (b), il est nécessaire de créer activement un objet de classe B dans la classe A pour remplir les fonctions en utilisant des méthodes de classe B (vous ne devez pas vous soucier des méthodes statiques et d'autres situations ici). Cela équivaut à la classe A étant responsable de la gestion de tout le cycle de vie des objets de classe B. Dans des cas extrêmement simples, il semble qu'il n'y ait aucun problème aux nouveaux objets d'une autre classe dans une classe, mais la relation collaborative entre les classes d'applications et les classes complexes est souvent multilatérale. Nous ne savons pas combien d'objets alternatifs sur lesquels la mise en œuvre d'une fonction de classe s'appuiera pour coopérer. Par conséquent, la création d'objets dans une classe et la gestion de l'ensemble du cycle de vie de l'objet entraîneront un couplage de code élevé et une complexité inimaginable. Imaginez donc que si nous pouvons remettre le cycle de vie d'un objet à un composant tiers pour la gestion, et lorsqu'une classe a besoin d'un autre objet, le composant tiers sera créé directement. De cette façon, la classe ne peut se concentrer que sur la mise en œuvre de ses propres fonctions sans gérer le cycle de vie des autres objets de classe, les fonctions d'une telle classe sont beaucoup plus simples. Oui, vous devez avoir compris que le printemps est ce composant tiers. Nous avons juste besoin de dire à Spring (conteneur) quels objets doivent être gérés, et nous n'avons pas à nous soucier de la façon dont le framework Spring crée des objets. De cette façon, lorsqu'un certain classe A nécessite un objet de classe B, si la classe B a été déclarée et remise à la gestion de conteneurs de ressort, alors lorsque le programme s'exécute vers la classe A et nécessite la classe B, le conteneur de ressort injecte des objets de classe B dans la classe A par injection de dépendance pour aider à remplir les fonctions commerciales. Grâce à l'injection de dépendance de composants tiers, les objets n'ont plus besoin de créer et de gérer les dépendances entre les classes elles-mêmes. Il existe également de nombreuses façons de créer une injection de dépendance d'objets, tels que l'injection d'interface, l'injection de méthode de construction, l'injection de méthode du secteur, etc. En parlant de cela, vous devriez avoir une compréhension relativement simple de l'injection de dépendance. Quant à savoir pourquoi l'injection de dépendance est nécessaire, l'article ci-dessus l'a déjà expliqué très clairement. Afin de réduire le couplage entre les composants du code, nous devons d'abord utiliser des exemples simples pour ressentir intuitivement les avantages de l'injection de dépendance sur la gestion des objets vous-même -
La classe publique l'homme implémente la voiture humaine {private qqcar; public man () {this.car = new qqcar (); } @Override public void xiabibi () {} public void drivecar () {car.drive (); }}Il y a deux implémentations de la voiture d'interface: Mercedes-Benz et QQ Car. Dans les codes ci-dessus de l'homme et du QQCAR, le conducteur vétéran n'a créé que des objets de voiture QQ via le constructeur, de sorte qu'il ne peut que conduire la voiture QQ. Alors, que devrait faire le conducteur vétéran s'il veut conduire Mercedes-Benz? Lui demandez-vous de recréer l'objet Mercedes-Benz? Un tel code hautement couplé semble être impuissant, nous allons donc apporter quelques améliorations au code ci-dessus en injectant des objets:
La classe publique l'homme implémente humain {voiture privée; homme public (voiture voiture) {this.car = voiture; } @Override public void xiabibi () {} public void drivecar () {car.drive (); }}Le code ci-dessus bloque des objets spécifiques basés sur les caractéristiques polymorphes par l'injection d'interface constructeur, afin que les pilotes vétérans puissent conduire ce qu'ils veulent. C'est l'avantage de l'injection de dépendance.
AOP (programmation orientée vers l'aspect), programmation orientée vers le visage. Dans le développement quotidien, lorsque nous remplissons une certaine fonction commerciale, nous écrivons beaucoup de code. Lorsque nous optimisons enfin le code, nous constatons que le code qui complète l'entreprise peut ne être seulement deux phrases et que les autres ne sont pas très pertinents pour cette partie de l'entreprise. Il est complètement extrait juste pour implémenter un certain code technologique. Donc, naturellement, nous l'extraire dans une classe d'outils, afin que tout ce que vous utilisez soit OK pour simplement appeler la méthode de l'outil. Regardons-le un peu plus haut. En plus de remplir les fonctions commerciales connexes, les composants fonctionnels de chaque module commercial impliquent des opérations supplémentaires telles que les journaux, les transactions et le contrôle de sécurité. Ce ne sont pas les fonctions principales du module, mais elles sont indispensables. Si ces fonctions supplémentaires sont ajoutées au code, chaque composant du système commercial apparaîtra trop répétitif et rendra le code commercial confus et pas assez pur. Pour le moment, vous demandez à Dieu, votre code d'entreprise ne peut-il se concentrer que sur la mise en œuvre de l'entreprise et ignorer les choses non pertinentes telles que les journaux, les transactions, etc.? Oh, Dieu a dit que c'était OK, donc il y avait AOP. Si le but de l'injection de dépendance est de maintenir des composants coopératifs dans un état de couplage relativement lâche, AOP sépare les fonctions réparties sur l'application pour former des composants réutilisables. Dans les termes, les journaux, les transactions, etc. de laïque sont tous des composants réutilisables. Nous pouvons extraire complètement les journaux, les transactions, la sécurité et d'autres codes fonctionnels diffusés dans diverses parties du code commercial et devenir un composant d'outils distinct. Déclarez-le comme une section fonctionnelle dans la configuration de Spring, puis dites à Spring où et quand vous souhaitez utiliser (couper) ces composants réutilisables. Ceci est mon interprétation simple de la section orientée vers le visage. Cet article n'est qu'une introduction, donc le blogueur expliquera brièvement le concept et ne fera pas de code ou de configuration spécifiques. Il sera présenté dans les articles de blog ultérieurs. Bienvenue pour jeter un œil.