Compréhension de SpringAOP

AOP (Aspect Orient Programming), en complément de la programmation orientée objet, est largement utilisé pour gérer certains services au niveau système avec des propriétés transversales, telles que la gestion des transactions, les contrôles de sécurité, la mise en cache, la gestion des pools d'objets, etc. . La clé de la mise en œuvre d'AOP réside dans le proxy AOP créé automatiquement par le framework AOP. Les proxys AOP peuvent être divisés en deux catégories : les proxys statiques et les proxys dynamiques font référence à la compilation à l'aide des commandes fournies par le framework AOP, afin qu'ils puissent. être généré pendant la phase de compilation. La classe proxy AOP est également appelée amélioration au moment de la compilation ; tandis que le proxy dynamique utilise le proxy dynamique JDK, CGLIB, etc. pour générer « temporairement » la classe proxy dynamique AOP dans la mémoire au moment de l'exécution, donc elle est également appelée amélioration de l'exécution.

La valeur d'existence de l'AOP

Dans la programmation POO traditionnelle, les objets sont au cœur de l'ensemble du système logiciel. Il est composé d'une série d'objets interdépendants, et ces objets seront résumés en classes une par une. one. Et permet l’utilisation de l’héritage de classe pour gérer les relations générales à spécifiques entre les classes. À mesure que l'échelle des logiciels augmente et que les applications sont progressivement mises à niveau, certains problèmes difficiles à résoudre avec la POO apparaissent progressivement.

Nous pouvons analyser et résumer une série d'objets avec certains attributs et comportements, et former une fonction logicielle complète grâce à la collaboration entre ces objets. Puisque les objets peuvent être hérités, nous pouvons résumer les attributs ayant les mêmes fonctions ou caractéristiques dans un système de structure de classes hiérarchique. Avec l'expansion continue des spécifications logicielles, le nombre croissant de divisions de travail spécialisées et le nombre croissant de pratiques d'application de la POO, certains problèmes que la POO ne peut pas résoudre correctement ont été révélés.

Supposons maintenant qu'il y ait 3 morceaux de code complètement similaires dans le système. Ces codes sont généralement complétés par "copier" et "coller". Le logiciel développé via cette méthode de "copier" et "coller" est tel. comme le montre la figure 1.

Figure 1. Logiciel contenant le même code à plusieurs endroits

En voyant le diagramme schématique présenté dans la figure 1, certains lecteurs ont peut-être découvert ces inconvénients approche : si un jour, le segment de code sombre de la figure 1 doit être modifié, devez-vous ouvrir le code à trois endroits pour le modifier ? Que se passerait-il si ce code était contenu non pas à 3 endroits, mais à 100, voire 1 000 endroits ?

Afin de résoudre ce problème, nous définissons généralement la partie du code sombre comme indiqué dans la figure 1 comme méthode, puis appelons la méthode dans les trois segments de code. De cette manière, la structure du système logiciel est illustrée à la figure 2.

Figure 2 Implémentation des fonctions du système via des appels de méthode

Pour le système logiciel illustré à la figure 2, si vous devez modifier le code dans la partie sombre, il suffit de le modifier. Un seul endroit suffit. Peu importe le nombre d'endroits dans l'ensemble du système qui appellent cette méthode, le programme n'a pas besoin de modifier ces endroits, seule la méthode appelée peut être modifiée - de cette façon, la complexité de la maintenance ultérieure de la méthode est augmentée. le logiciel est considérablement réduit.

Pour les méthodes 1, 2 et 3 présentées dans la figure 2, vous devez toujours appeler explicitement la méthode dark, qui peut résoudre la plupart des scénarios d'application. Mais pour certains cas plus particuliers : l'application nécessite que la méthode 1, la méthode 2 et la méthode 3 soient complètement séparées de la méthode dark - la méthode 1, la méthode 2 et la méthode 3 n'ont pas besoin d'appeler directement la méthode dark, alors comment faire le résoudre ?

Étant donné que les exigences du système logiciel changent très fréquemment, seules les fonctions commerciales de base ont été implémentées dans les premières méthodes de conception du système 1, méthode 2 et méthode 3. Après un certain temps, nous devons fournir des méthodes pour la méthode 1, la méthode 2. , et méthode 3. Augmenter le contrôle des transactions ; après un certain temps, le client a proposé la méthode 1, la méthode 2 et la méthode 3, qui nécessitaient une vérification de la légalité de l'utilisateur, et seuls les utilisateurs légitimes peuvent exécuter ces méthodes après un certain temps, le client a proposé la méthode 1 ; , Méthode 2 encore, La méthode 3 devrait ajouter la journalisation ; au bout d'un moment, le client a demandé à nouveau... Face à une telle situation, que devons-nous faire ? Il existe généralement deux approches :

Rejeter directement la demande du client en fonction des spécifications de la demande.

Adopter les besoins et répondre aux besoins des clients.

La première approche n'est évidemment pas bonne. Les clients sont Dieu et nous devons faire de notre mieux pour répondre à leurs besoins. La deuxième approche est généralement adoptée, alors comment la résoudre ? Devons-nous d'abord définir une nouvelle méthode, puis modifier la méthode 1, la méthode 2 et la méthode 3, et ajouter de nouvelles méthodes à appeler ? La charge de travail pour y parvenir n’est pas minime ! Nous espérons avoir une méthode spéciale : tant que nous définissons cette méthode, il n'est pas nécessaire de l'appeler explicitement dans la méthode 1, la méthode 2 et la méthode 3. Le système exécutera "automatiquement" cette méthode spéciale.

L'idée ci-dessus semble magique et même un peu irréaliste, mais elle est en fait tout à fait réalisable. La technologie permettant d'atteindre cette exigence est l'AOP. AOP est spécifiquement utilisé pour traiter les problèmes transversaux répartis dans divers modules (différentes méthodes) du système. Dans les applications Java EE, AOP est souvent utilisé pour gérer certains services transversaux au niveau du système, tels que la gestion des transactions et les inspections de sécurité. . , mise en cache, gestion de pool d'objets, etc., AOP est devenu une solution très courante.

Analyse du principe Spring AOP

Comme vous pouvez le savoir grâce à l'introduction précédente : le proxy AOP est en fait un objet généré dynamiquement par le framework AOP, qui peut être utilisé comme objet cible. Le proxy AOP contient toutes les méthodes de l'objet cible, mais les méthodes du proxy AOP sont différentes des méthodes de l'objet cible : les méthodes AOP ajoutent un traitement amélioré à des points d'entrée spécifiques et rappellent les méthodes de l'objet cible.

Les méthodes contenues dans le proxy AOP et le diagramme de méthodes de l'objet cible sont présentés dans la figure 3.

Figure 3. Méthodes de proxy AOP et méthodes d'objet cible

Le proxy AOP de Spring est généré et géré par le conteneur IoC de Spring, et ses dépendances Il est également géré par le conteneur IoC. Par conséquent, les proxys AOP peuvent cibler directement d'autres instances de bean dans le conteneur, une relation fournie par l'injection de dépendances du conteneur IoC.

En ce qui concerne la programmation AOP, il n'y a que 3 parties qui nécessitent la participation des programmeurs :

Définir les composants métier communs.

Définissez les points d'entrée. Un point d'entrée peut traverser plusieurs composants métier.

Définissez le traitement amélioré, qui est une action de traitement intégrée au cadre AOP pour les composants métier ordinaires.

La première partie des 3 parties ci-dessus est la chose la plus courante et ne nécessite aucune explication supplémentaire. Ensuite, la clé de la programmation AOP est de définir les points d’entrée et de définir le traitement d’amélioration. Une fois le point d'entrée approprié et le traitement amélioré définis, le framework AOP générera automatiquement un proxy AOP, et la méthode proxy AOP a approximativement la formule suivante :

Méthode d'objet proxy = Méthode améliorée de traitement de l'objet proxy

Dans la définition métier ci-dessus, il n'est pas difficile de constater que le principe de mise en œuvre de Spring AOP est en fait très simple : le framework AOP est responsable de la génération dynamique de la classe proxy AOP, et les méthodes de cette classe proxy sont composés de méthodes d'objet cible de conseil et de rappel.

Pour la structure d'appel du logiciel illustrée dans la figure 2 mentionnée précédemment : lorsque la méthode 1, la méthode 2, la méthode 3... doivent toutes appeler une méthode avec des propriétés "transversales", l'approche traditionnelle est en place au programmeur de modifier manuellement la méthode 1, la méthode 2, la méthode 3... et d'appeler cette méthode "transversale" via le code, mais cette approche a une mauvaise évolutivité car le code doit être modifié à chaque fois.

Le framework AOP est donc apparu. Le framework AOP peut générer "dynamiquement" une nouvelle classe proxy, et cette classe proxy contient la méthode 1, la méthode 2, la méthode 3... et ajoute également la possibilité d'appeler cela A. méthode "transversale" - mais cet appel est pris en charge par la classe proxy générée automatiquement par le framework AOP, il a donc une excellente évolutivité. Les programmeurs n'ont pas besoin de modifier manuellement le code de la méthode 1, de la méthode 2 et de la méthode 3. Les programmeurs n'ont qu'à définir le point d'entrée - la classe proxy AOP générée par le framework AOP contient la nouvelle méthode 1, la méthode d'accès 2 et la méthode 3. , et Le framework AOP décidera s'il convient de rappeler les méthodes avec des propriétés « transversales » dans la méthode 1, la méthode 2 et la méthode 3 en fonction du point d'entrée.

En bref : le secret du principe AOP est de générer dynamiquement une classe proxy, qui implémente l'appel de la figure 2 - cet appel ne nécessite pas que le programmeur modifie le code.

Résumé

AOP est largement utilisé pour traiter certains services au niveau système avec des propriétés transversales. L'émergence de l'AOP est un bon complément à la POO, qui permet aux développeurs de gérer les services avec des propriétés transversales de manière plus élégante. Quel que soit le type d'implémentation AOP, qu'il s'agisse d'AspectJ ou de Spring AOP, ils doivent tous générer dynamiquement une classe proxy AOP. La seule différence est le moment de génération de la classe proxy AOP : AspectJ génère la classe proxy AOP au moment de la compilation. il a donc de meilleures performances, mais nécessite l'utilisation d'un compilateur spécifique pour le traitement ; Spring AOP utilise le runtime pour générer des classes proxy AOP, il n'est donc pas nécessaire d'utiliser un compilateur spécifique pour le traitement. Étant donné que Spring AOP doit générer un proxy AOP à chaque exécution, les performances sont légèrement moins bonnes.

Pour plus d'articles sur la compréhension de SpringAOP, veuillez faire attention au site Web PHP chinois !