POURQUOI
Au début de sa naissance, l'objectif principal de la création du printemps était de remplacer les technologies Java de niveau d'entreprise plus lourdes, en particulier l'EJB. Par rapport à l'EJB, le printemps fournit un modèle de programmation plus léger et plus simple.
QUOI
Spring est un framework open source créé pour la première fois par Rodjohnson. Spring a été créé pour résoudre la complexité du développement d'applications au niveau de l'entreprise. L'utilisation de Spring peut permettre aux JavaBeans simples d'implémenter des choses que seule EJB pourrait accomplir auparavant. Le printemps ne se limite pas au développement côté serveur, toute application Java peut bénéficier du printemps en termes de simplicité, de testabilité et de couplage lâche.
Aujourd'hui, le printemps est impliqué dans le développement mobile, l'intégration des API sociaux, la base de données NoSQL, le cloud computing et les mégadonnées. Au fil du temps, l'EJB a également adopté les concepts d'injection de dépendance (DI) et de programmation orientée vers l'aspect (AOP). En bref, la mission la plus fondamentale de Spring est de simplifier le développement de Java
COMMENT
Afin de réduire la complexité du développement de Java, le printemps adopte une stratégie clé de 4 minutes
La programmation invasive légère et minimale basée sur POJO permet un couplage lâche par injection de dépendance et orienté vers l'interface
La programmation déclarative basée sur les sections et les conventions réduit le code de style à travers des sections et des modèles
Potentiel de pojo
De nombreux cadres obligent les applications à hériter de leurs classes ou à implémenter leurs interfaces, ce qui conduit les applications liées au cadre, qui est une programmation invasive, ce qui entraîne l'incapacité de réutiliser les blocs de code. Spring s'efforce d'éviter de gâcher votre code d'application en raison de sa propre API. Dans les applications construites au printemps, ses classes n'ont généralement aucune trace de signes que vous utilisez Spring.
classe publique HelloworldBean {public String Sayshello () {return "Hello World"; }} L'exemple de code ci-dessus représente une classe Java très simple et ordinaire (POJO). Vous ne pouvez pas dire que c'est un composant à ressort. La programmation non invasive de Spring se reflète dans cette classe qui peut jouer un rôle dans les applications de printemps et les applications non spring. Ce morceau de code ne reflète pas réellement les fonctions de Spring, et les connaissances suivantes sont toujours nécessaires.
Injection de dépendance (injection de la classe elle-même dépendante)
L'injection de dépendance n'est pas si élevée au printemps, bien qu'elle ait évolué en une technique de programmation complexe ou un concept de modèle de conception. Ceci est compris au printemps, injectant les dépendances. Une application ayant une signification pratique nécessite plusieurs classes pour collaborer entre elles pour compléter une logique métier spécifique. La pratique traditionnelle est que chaque objet est responsable de la gestion des références à des objets liés à lui-même (cet objet connexe est l'objet qui dépend de l'objet exprimé au printemps), mais cela rendra difficile le test hautement couplé et le code.
Considérez le code suivant
/ ** Ce nom de classe difficile à bouche a été spécialement nommé par l'auteur pour s'adapter à une scène simulée * Cette classe représente le chevalier qui a sauvé la fille * créée par Wung le 2016/8/25. * / classe publique DamselRescUingKnight implémente Knight {private RescuseAmselquest Quest; / ** * Créé sauvéamselquest dans son constructeur * Cela rend DamselRescUingKnight et RescuingDamselquest dans son constructeur couplé ensemble * / public damselrescUingKnight () {this.quest = new RescuseAlQuest ();} public Void EmbarkOnQuest () {quête.embark ();}} Le couplage a deux côtés. D'une part, le code étroitement couplé est difficile à tester, à réutiliser et à comprendre, et il y aura des bugs de type "combattre le gobelin". D'un autre côté, un certain degré de couplage est nécessaire et différentes classes doivent interagir de manière appropriée.
Le problème se pose, alors comment le printemps l'a-t-il résolu?
Au printemps, grâce à l'injection de dépendance (DI), les dépendances entre les objets sont définies par les composants tiers du système qui coordonnent chaque objet lors de la création de l'objet. En d'autres termes, les objets n'ont qu'à gérer leurs propriétés internes sans créer ou gérer leurs dépendances par eux-mêmes, et les dépendances seront automatiquement injectées dans les objets qui en ont besoin.
/ ** * Ce chevalier peut effectuer diverses tâches d'aventure au lieu de la précédente pour sauver la fille * créée par Wung le 2016/8/25. * / classe publique BraveKnight implémente Knight {private Quest Quest; / ** * BraveKnight ne crée pas de types d'aventure à part entière, mais passe les tâches d'aventure comme paramètres pendant la construction * Ceci est l'un des façons d'injection de dépendance: injection de constructeur * / public BraveKnight (quête Quest) {this.quest = Quest;} Public Void Embarkonquest () {quête. BraveKnight n'est associé à aucune mise en œuvre de quêtes spécifique. Tant qu'une tâche implémente l'interface de quête, peu importe de quel type d'aventure est. Cela atteint le but du couplage en vrac
Si un objet indique uniquement une dépendance via une interface, cette dépendance peut être remplacée par différentes implémentations en béton sans que l'objet lui-même ne soit conscient.
Alors maintenant, injectons un sens pratique
Pour le code ci-dessus, nous injecterons une tâche d'aventure avec une implémentation spécifique dans le Brave Knight
/ ** La mission d'aventure de tuer des dragons (cet auteur est une bonne deuxième classe) * créé par Wung le 2016/8/25. * / classe publique SlaydragonQuest implémente Quest {private PrintStream stream; public slaydragonquest (printStream stream) {this.stream = stream;} public void embark () {stream.print ("Slay the Dragon");}}Alors maintenant, la question est de savoir comment injecter l'objet PrintStream dont il dépend dans SlaydragonQuest, comment injecter l'objet quête dont il dépend dans BraveKnight. Le ressort susmentionné gérera ces dépendances de manière centralisée, et le comportement de la création de collaboration entre les composants d'application est généralement appelé assemblage (câblage), c'est-à-dire l'injection. Spring fournit une variété de méthodes d'assemblage pour introduire plus en détail plus tard. Ici, nous introduisons brièvement l'assemblage basé sur XML et l'assemblage basé sur les annotations Java.
<! - Ceci est un processus d'assemblage. Déclarez Slaydragonquest comme un haricot, nommé "Quest". Parce qu'il s'agit d'une injection de constructeur, utilisez la valeur d'attribut constructeur-arg pour représenter la valeur injectée. Ce processus résout le problème précédent. Injectez l'objet PrintStream dans l'objet SlayDragonQuest -> <bean id = "Quest"> <Constructor-Arg Value = "# {t (System) .out}"> </ Constructor-arg> </anEp> <! - Ce processus est le même que ci-dessus. BraveKnight déclare un haricot nommé "Knight" (ce nom n'est pas nécessairement utilisé) puis le paramètre constructeur de BraveKnight est nécessaire pour être le type de quête. À l'heure actuelle, un autre haricot est passé dans la référence, qui est la référence du bean avec le nom "Quest" ci-dessus. À l'heure actuelle, l'injection de constructeur de BraveKnight est également terminée-> <bean id = "Knight"> <Constructor-arg ref = "Quest"> </ Constructor-arg> </ank>Spring fournit des configurations basées sur Java qui peuvent être utilisées comme alternative à XML
/ ** Fichier de configuration basé sur Java implémente l'assemblage d'objets * créé par Wung le 2016/8/26. * / @ ConfigurationPublic class knightconfig {@bean public knight () {return new BraveKnight (quête ()); } @Bean public Questond () {return new SlaydragonQuest (System.out); }}Les effets sont les mêmes et l'explication spécifique est décrite en détail dans le chapitre suivant. Revoyons à nouveau. Il a été dit que le printemps gérera automatiquement les dépendances entre les objets, alors quel est ce type de gestionnaire? La réponse est le contexte d'application, qui est un conteneur pour le ressort qui peut charger les définitions des haricots et les assembler. Le contexte d'application de printemps est seul responsable de la création et de l'assemblage d'objets. En fait, il existe de nombreuses façons d'implémenter la différence entre ce contexte, juste la différence de configuration de chargement. Voyons un moyen de charger la configuration.
classe publique KnightMain {public static void main (String [] args) {annotationConfigApplicationContext context = new AnnotationConfigApplicationContext (knightConfig.class); // La définition du bean peut être obtenue à partir du fichier de configuration. Knight Knight = context.getBean (knight.class); knight.embarkonquest (); context.close (); }}Appliquer la coupe du visage
DI peut conserver les composants logiciels collaboratifs à coupler de manière lâche, tandis que la programmation des facettes vous permet de séparer les fonctions partout dans l'application pour former des composants réutilisables, et, plus précisément, c'est une technologie qui anime les systèmes logiciels pour s'efforcer. Qu'est-ce qu'un objectif? Les services système tels que la journalisation, la gestion des transactions et la gestion de la sécurité doivent souvent être intégrés dans d'autres composants qui ont eux-mêmes une logique commerciale. Ces services système sont généralement appelés focuss croisés car ils seront réutilisés à plusieurs endroits, couvrant plusieurs composants du système. Autrement dit, vous extraire les services qui doivent être réutilisés à partir de divers autres composants, mais comment les utiliser? En fait, il s'agit d'insérer la méthode dans les endroits que vous devez utiliser lorsque vous l'utilisez. Cependant, selon ce terme "section", il doit être exprimé comme extraire le composant réutilisé en tant que section et couper la section à travers le composant en cas de besoin. Ainsi, de cette manière, les applications de base n'ont pas besoin de connaître l'existence de ces sections, et les sections n'intégreront pas la logique métier dans les applications de base.
/ ** Une classe de chanteur est utilisée pour louer les chevaliers, c'est-à-dire pour servir les chevaliers * créés par Wung le 2016/8/26. * / classe publique Minstrel {Stream privé PrintStream; Minstrel public (Stream PrintStream) {this.Stream = Stream; } // exécuter public void singBeforequest () {Stream.print ("begin"); } // Exécuter public void singafterQuest () {Stream.print ("end"); }} classe publique Braveknight implémente Knight {quête privée quête; ménestrel privé; / ** * BraveKnight ne crée pas de types d'aventure à part entière, mais passe les tâches d'aventure comme paramètres dans la construction * Ceci est l'une des façons d'injection de dépendance: l'injection de constructeur * /// public BraveKnight (Quest Quest) {// this.Quest = Quest; //} public BraveKnight (Quest Quest) minestrel) {this.quest = quête; this.minStrel = minestrel;} public void EmbarkOnQuest () {minestrel.singbeforequest (); quête.embark (); minestrel.singafterQuest ();}} À cette époque, le brave chevalier a commencé à s'exécuter, mais il a constaté que dans ses fonctions, ce n'était pas seulement un risque, mais maintenant il devait gérer le chanteur pour le louer, mais cela ne devrait pas appartenir à la catégorie qui devrait être gérée. Par conséquent, en utilisant l'idée des sections, nous devons extraire le comportement de louange du chanteur et devenir une section. Avant que les Cavaliers ne prennent le risque, cette section sera réduite et exécutera la méthode SingBeforequest et exécutera la méthode SingafterQuest après le risque. Cela réalisera donc le code qui n'a pas besoin d'être loué par le chevalier, et le chanteur n'existe pas dans l'objet du chevalier. Il louera non seulement le chevalier, mais louera également n'importe qui tant que les autres utilisent cette section pour entrer.
<! - signifie que la configuration du bean avec l'ID ci-dessus en tant que ménestrel en tant que section configure réellement le chanteur en tant que section -> Aspect Ref = "Minstrel"> <! - Définition du point d'entrée, c'est-à-dire où utiliser la section expression = "Exécution (* * .embarkonQuest (..)) est une méthode d'expression de point d'aspect jalon. Exécution de post-note avant et après la coupe du point d'entrée -> </aop: après> </ aop: avant> </aop: Pointcut> </aop: </aop: config>
La situation est que le ménestrel est toujours un Pojo indépendant, et le contexte du printemps l'a transformé en section. La chose la plus importante est que le chevalier n'a aucune idée de l'existence de cette section pour le moment. Ce n'est qu'un petit châtaignier, qui peut en fait faire beaucoup de choses importantes.
Utilisez des modèles pour éliminer le code de style
Il y a une situation où lorsque nous utilisons JDBC pour accéder à la base de données pour interroger les données, le processus complet nécessite l'établissement de connexions, la création d'objets d'instruction, le traitement des ensembles de résultats, l'interrogation et la fermeture de diverses connexions. De plus, diverses exceptions sont capturées, puis les requêtes dans divers scénarios nécessitent une telle répétition minutieuse. JDBC n'est pas seulement le seul cas où il y a beaucoup de code de style comme celui-ci. Spring vise à éliminer le code de style via l'encapsulation du modèle, tel que JDBCTemplate de Spring.
Accueillir votre haricot
Dans les applications basées sur le printemps, vos objets d'application vivent dans des conteneurs de printemps, qui sont responsables de la création d'objets assemblés et de la gestion de leur cycle de vie. Alors, qu'est-ce que le conteneur à ressort? Il n'y a pas seulement un type de conteneur. Le printemps est livré avec plusieurs implémentations de conteneurs. Il est divisé en deux catégories: les usines de haricots, qui sont les conteneurs les plus simples pour fournir un support de DI de base. Le contexte d'application est relativement avancé et fournit des services de niveau de cadre d'application. La plupart du temps, le contexte de l'application est plus populaire.
Le contexte d'application est également divisé en de nombreuses façons différentes de charger des configurations.
Diverses fonctionnalités de printemps
Résumer
Spring est une technologie de cadre qui peut simplifier le développement, et son contenu principal est DI et AOP.
Ce qui précède est les ragots sur cet article - comprennent progressivement le contenu de Spring, j'espère qu'il sera utile à tout le monde. Les amis intéressés peuvent continuer à se référer à ce site:
Exemple de démarrage de Springmvc
Explication détaillée du code pour injecter la valeur d'attribut à l'aide de fichiers de configuration et @Value à Spring
Exemple de code détaillé de redis intégré Spring
S'il y a des lacunes, veuillez laisser un message pour le signaler.