Introduction à Spring

Le framework Spring a été développé par Rod Johnson, et la première version a été publiée en 2004. Spring est un framework extrait du développement réel, il gère donc de nombreuses étapes courantes du développement, ne laissant aux développeurs que les parties spécifiques à l'application, ce qui améliore grandement l'efficacité de développement des applications d'entreprise.

Les avantages de Spring sont résumés comme suit :

  • Conception peu invasive avec très peu de pollution du code.
  • Indépendant de divers serveurs d'applications. Les applications basées sur le framework Spring peuvent véritablement réaliser la promesse « Écrire une fois, exécuter partout ».
  • Le conteneur IoC de Spring réduit la complexité du remplacement des objets métier et améliore le découplage entre les composants.
  • Le support AOP de Spring permet de gérer de manière centralisée les tâches courantes telles que la sécurité, les transactions et la journalisation, offrant ainsi une meilleure réutilisation.
  • L'ORM et le DAO de Spring offrent une bonne intégration avec les frameworks de persistance tiers et simplifient l'accès de bas niveau aux bases de données.
  • Spring est très ouvert et ne force pas les applications à dépendre entièrement de Spring. Les développeurs sont libres de choisir une partie ou la totalité du framework Spring.

Le diagramme de structure de composition du framework Spring est le suivant :

spring-overview

Mécanisme central de Spring

Gestion des Beans

Les programmes accèdent principalement aux Beans du conteneur via le conteneur Spring. ApplicationContext est l'interface la plus couramment utilisée du conteneur Spring. Cette interface possède les deux classes d'implémentation suivantes :

  • ClassPathXmlApplicationContext : recherche les fichiers de configuration dans le chemin de chargement des classes et crée le conteneur Spring en fonction des fichiers de configuration.
  • FileSystemXmlApplicationContext : recherche les fichiers de configuration à partir d'un chemin relatif ou absolu dans le système de fichiers et crée le conteneur Spring en fonction des fichiers de configuration.
public class BeanTest{
    public static void main(String args[]) throws Exception{
        ApplicationContext ctx = new ClassPathXmlApplicationContext("beans.xml");
        Person p = ctx.getBean("person", Person.class);
        p.say();
    }
}

Utiliser Spring dans Eclipse

Dans les outils IDE tels qu'Eclipse, les utilisateurs peuvent créer leur propreUser Library, puis y placer toutes les archives JAR Spring. Bien sûr, ils peuvent également placer directement les archives JAR dans le/WEB-INF/librépertoire du projet. Toutefois, si vous utilisezUser Library, lorsque le projet est publié, les fichiers JAR référencés par la bibliothèque utilisateur doivent être publiés avec l'application, c'est-à-dire copier les fichiers JAR utilisés par la User Library vers le/WEB-INF/librépertoire. En effet, pour une application Web, lorsque Eclipse déploie une application Web, il ne copie pas les fichiers JAR de la bibliothèque utilisateur vers le/WEB-INF/librépertoire, et une copie manuelle est nécessaire.

Injection de dépendances

Le framework Spring a deux fonctions principales :

  • Le conteneur Spring agit comme une super-fabrique, responsable de la création et de la gestion de tous les objets Java. Ces objets Java sont appelés Beans.
  • Le conteneur Spring gère les dépendances entre les Beans dans le conteneur. Spring utilise une méthode appelée « injection de dépendances » pour gérer les dépendances entre les Beans.

En utilisant l'injection de dépendances, vous pouvez non seulement injecter des valeurs de propriétés ordinaires dans les Beans, mais aussi injecter des références vers d'autres Beans. L'injection de dépendances est une excellente méthode de découplage qui permet d'organiser les Beans ensemble via des fichiers de configuration, plutôt que de les coupler ensemble de manière codée en dur.

Comprendre l'injection de dépendances

Rod Johnson a été le premier à accorder une grande importance à la gestion des relations de collaboration des instances Java via des fichiers de configuration. Il a donné un nom à cette méthode : Inversion de contrôle (IoC). Plus tard, Martine Fowler lui a donné un autre nom : Injection de dépendances. Par conséquent, qu'il s'agisse d'injection de dépendances ou d'inversion de contrôle, la signification est exactement la même. Lorsqu'un objet Java (l'appelant) doit appeler une méthode d'un autre objet Java (l'objet dépendant), il existe généralement deux approches dans le modèle traditionnel :

  1. Approche originale : l'appelant créeactivementl'objet dépendant, puis appelle la méthode de l'objet dépendant.
  2. Modèle de fabrique simple : l'appelant trouve d'abord la fabrique de l'objet dépendant, puis obtientactivementl'objet dépendant via la fabrique, et enfin appelle la méthode de l'objet dépendant.

Remarquez le« activement »ci-dessus. Cela conduira inévitablement à un couplage codé en dur entre l'appelant et la classe d'implémentation de l'objet dépendant, ce qui est très défavorable pour la mise à niveau et la maintenance du projet. Après avoir utilisé le framework Spring, l'appelant n'a pas besoin deactivementobtenir l'objet dépendant. L'appelant doit seulementpassivementaccepter que le conteneur Spring attribue des valeurs aux variables membres de l'appelant. On peut voir qu'après avoir utilisé Spring, la façon dont l'appelant obtient l'objet dépendant passe d'une acquisition active à une acceptation passive — c'est pourquoi Rod Johnson a appelé cela Inversion de contrôle.

De plus, du point de vue du conteneur Spring, le conteneur Spring est chargé d'attribuer l'objet dépendant aux variables membres de l'appelant — ce qui équivaut à injecter l'instance dont il dépend dans l'appelant. Par conséquent, Martine Fowler a appelé cela injection de dépendances.

Injection par setter

L'injection par setter signifie que le conteneur IoC injecte des objets dépendants via les méthodes setter des variables membres. Cette méthode d'injection est simple et intuitive, c'est pourquoi elle est largement utilisée dans l'injection de dépendances de Spring.

Injection par constructeur

La façon de définir les dépendances à l'aide de constructeurs est appelée injection par constructeur. En termes simples, elle pousse Spring à exécuter, en interne, un constructeur avec des paramètres spécifiés via la réflexion. Lorsque le constructeur paramétré est exécuté, les paramètres du constructeur peuvent être utilisés pour initialiser les variables membres — c'est l'essence même de l'injection par constructeur.

Comparaison des deux méthodes d'injection

L'injection par setter présente les avantages suivants :

  • Elle est plus proche de l'écriture traditionnelle des JavaBean, ce qui la rend plus facile à comprendre et à accepter pour les développeurs. Définir les dépendances via des méthodes setter est plus intuitif et naturel.
  • Pour les dépendances complexes, si l’injection par constructeur est utilisée, le constructeur peut devenir trop volumineux et difficile à lire. Lorsque Spring crée une instance de Bean, il doit également instancier toutes ses instances dépendantes en même temps, ce qui entraîne une dégradation des performances. L’injection par setter peut éviter ces problèmes.
  • En particulier lorsque certaines variables membres sont facultatives, les constructeurs avec plusieurs paramètres sont encore plus encombrants.

Les avantages de l’injection par constructeur sont les suivants :

  • L’injection par constructeur peut déterminer l’ordre d’injection des dépendances dans le constructeur, les dépendances de priorité plus élevée étant injectées en premier.
  • Pour les Beans dont les dépendances n’ont pas besoin de changer, l’injection par constructeur est plus utile. Comme il n’y a pas de méthodes setter, toutes les dépendances sont définies dans le constructeur, il n’y a donc pas à s’inquiéter que le code ultérieur endommage les relations de dépendance.
  • Si les dépendances ne peuvent être définies que dans le constructeur, alors seul le créateur du composant peut modifier les dépendances du composant. Pour l’appelant du composant, les relations de dépendance internes du composant sont totalement transparentes, ce qui est davantage conforme au principe de forte cohésion.

Remarque :
Il est recommandé d’utiliser l’injection par setter comme approche principale et l’injection par constructeur comme complément. Pour les injections où la relation de dépendance n’a pas besoin de changer, essayez d’utiliser l’injection par constructeur ; pour les autres injections de dépendances, envisagez d’utiliser l’injection par setter.

Les Beans dans le conteneur Spring

Pour les développeurs, utiliser le framework Spring implique principalement deux choses : ① développer des Beans ; ② configurer des Beans. Pour le framework Spring, ce qu’il doit faire est de créer des instances de Bean selon le fichier de configuration et d’appeler les méthodes des instances de Bean pour réaliser l’« injection de dépendances » — c’est l’essence de ce que l’on appelle l’IoC.

Portées des Beans dans le conteneur

Lorsque vous créez une instance de Bean via le conteneur Spring, vous pouvez non seulement instancier l’instance de Bean, mais aussi spécifier une portée spécifique pour le Bean. Spring prend en charge les cinq portées suivantes :

  1. singleton : mode singleton. Dans tout le conteneur Spring IoC, une seule instance sera créée pour un Bean ayant la portée singleton.
  2. prototype : chaque fois qu’un Bean de portée prototype est obtenu via la méthode getBean() du conteneur, une nouvelle instance de Bean sera créée.
  3. request : pour une requête HTTP, un Bean de portée request ne générera qu’une seule instance. Cela signifie que, dans la même requête HTTP, chaque fois que le programme demande ce Bean, il obtient toujours la même instance. Cette portée n’est réellement effective que lorsque Spring est utilisé dans une application web.
  4. session : cette portée limite la définition du bean à une session HTTP. Elle n’est valide que dans le contexte d’un ApplicationContext Spring web-aware.
  5. global session : chaque session HTTP globale correspond à une instance de Bean. Dans les cas typiques, elle n’est effective que lors de l’utilisation d’un contexte portlet, et elle n’est également valide que dans les applications web.

Si la portée du Bean n’est pas spécifiée, Spring utilise la portée singleton par défaut. La création et la destruction de Beans de portée prototype sont relativement coûteuses. En revanche, une fois qu’une instance de Bean de portée singleton est créée, elle peut être réutilisée. Par conséquent, vous devriez essayer d’éviter de définir des Beans avec la portée prototype.

Injection de Beans collaborateurs avec l’autowiring

Spring peut câbler automatiquement les dépendances entre les Beans. Autrement dit, il n’est pas nécessaire de spécifier explicitement le Bean dépendant à l’aide de ref. À la place, le conteneur Spring inspecte le contenu du fichier de configuration XML et injecte le Bean dépendant dans le Bean appelant selon certaines règles.
L’autowiring Spring peut être spécifié via l’<beans/>élémentsdefault-autowireattribut. Cet attribut s’applique à tous les Beans du fichier de configuration. Il peut également être spécifié via l’<bean/>élémentsautowireattribut, qui n’affecte que ce Bean.

autowireetdefault-autowireIl peut accepter les valeurs suivantes :

  • no: L'autowiring n'est pas utilisé. Les dépendances des Beans doivent être définies via l'élément ref. C'est la configuration par défaut. Dans les environnements de déploiement plus vastes, il est déconseillé de modifier cette configuration ; configurer explicitement les collaborateurs peut produire des relations de dépendance plus claires.
  • byName: Autowiring basé sur les noms des méthodes setter. Le conteneur Spring recherche tous les Beans dans le conteneur, trouve un Bean dont l'id correspond au nom de la méthode setter auquel on a retiré le préfixe "set" et dont la première lettre est mise en minuscule, puis effectue l'injection. Si aucune instance de Bean correspondante n'est trouvée, Spring n'effectuera aucune injection.
  • byType: Autowiring basé sur le type du paramètre de la méthode setter. Le conteneur Spring recherche tous les Beans dans le conteneur. S'il existe exactement un Bean dont le type correspond au type du paramètre de la méthode setter, ce Bean est automatiquement injecté ; si plusieurs Beans de ce type sont trouvés, une exception est levée ; si aucun Bean de ce type n'est trouvé, rien ne se passe et la méthode setter ne sera pas appelée.
  • constructor: Similaire à byType, sauf qu'il est utilisé pour faire correspondre automatiquement les paramètres du constructeur. Si le conteneur ne peut pas trouver exactement un Bean correspondant au type du paramètre du constructeur, une exception sera levée.
  • autodetect: Le conteneur Spring décide lui-même s'il doit utiliser le constructeur ou la stratégie byType en fonction de la structure interne du Bean. Si un constructeur par défaut est trouvé, la stratégie byType sera appliquée.

Lorsqu'un Bean utilise à la fois des dépendances autowired et des dépendances explicitement spécifiées via ref, les dépendances explicitement spécifiées ont priorité sur les dépendances autowired. Pour les applications volumineuses, l'auto-câblage est déconseillé. Bien que l'auto-câblage puisse réduire la charge de travail des fichiers de configuration, il réduit considérablement la clarté et la transparence des relations de dépendance. L'assemblage des dépendances repose sur les noms et les types des propriétés dans les fichiers sources, ce qui fait que le couplage entre Beans est réduit au niveau du code, ce qui n'est pas propice à un découplage de haut niveau.

<!--通过设置可以将Bean排除在自动装配之外-->
<bean id="" autowire-candidate="false"/>

<!--除此之外，还可以在beans元素中指定，支持模式字符串，如下所有以abc结尾的Bean都被排除在自动装配之外-->
<beans default-autowire-candidates="*abc"/>

Trois façons de créer des Beans

Créer des instances de Bean avec des constructeurs

L'utilisation d'un constructeur pour créer une instance de Bean est le cas le plus courant. Si l'injection par constructeur n'est pas utilisée, Spring appellera en interne le constructeur sans argument de la classe Bean pour créer l'instance. Par conséquent, la classe Bean doit fournir un constructeur sans argument.

Lorsqu'on utilise le constructeur par défaut pour créer une instance de Bean, Spring effectue une initialisation par défaut de toutes les propriétés de l'instance de Bean, c'est-à-dire que toutes les valeurs de type primitif sont initialisées à 0 ou false, et toutes les valeurs de type référence sont initialisées à null.

Créer des Beans avec des méthodes de fabrique statiques

Lorsqu'on utilise une méthode de fabrique statique pour créer une instance de Bean, l'attribut class doit également être spécifié. Toutefois, à ce moment, l'attribut class ne spécifie pas la classe d'implémentation de l'instance de Bean, mais la classe de fabrique statique. Spring utilise cet attribut pour savoir quelle classe de fabrique créera l'instance de Bean.

De plus, l'attribut factory-method doit être utilisé pour spécifier la méthode de fabrique statique. Spring appellera la méthode de fabrique statique pour renvoyer une instance de Bean. Une fois l'instance de Bean spécifiée obtenue, les étapes de traitement suivantes de Spring sont exactement les mêmes que lors de la création d'une instance de Bean à l'aide d'une méthode ordinaire. Si la méthode de fabrique statique nécessite des paramètres, utilisez le<constructor-arg.../>élément permettant de spécifier les paramètres de la méthode de fabrique statique.

Création de Beans en appelant des méthodes de fabrique d'instance

La seule différence entre une méthode de fabrique d'instance et une méthode de fabrique statique est que l'appel d'une méthode de fabrique statique ne nécessite qu'une classe de fabrique, tandis que l'appel d'une méthode de fabrique d'instance nécessite une instance de fabrique. Lors de l'utilisation d'une méthode de fabrique d'instance, l'<bean.../>élément n'a pas besoin de l'attribut class. Pour configurer une méthode de fabrique d'instance, utilisezfactory-beanpour spécifier l'instance de fabrique.
Les<bean.../>élément permettant de créer un Bean à l'aide d'une méthode de fabrique d'instance nécessite de spécifier les deux attributs suivants :

  • factory-bean : La valeur de cet attribut est l'id du Bean de fabrique.
  • factory-method : Cet attribut spécifie la méthode de fabrique de la fabrique d'instance.

Si des paramètres doivent être passés lors de l'appel de la méthode de fabrique d'instance, utilisez l'<constructor-arg.../>élément pour déterminer les valeurs des paramètres.

Coordination de Beans de portées différentes

Lorsqu'un Bean de portée singleton dépend d'un Bean de portée prototype, un problème de synchronisation se produit. En effet, lorsque le conteneur Spring s'initialise, il pré-initialise tous lessingleton Bean, et commesingleton Beandépend deprototype Bean, lorsque Spring s'initialisesingleton Beanavant, il créera d'abordprototypeBean— et seulement ensuite créersingleton Bean, puisprototype Beaninjectersingleton Bean。
Il existe deux façons de résoudre le problème de synchronisation :

  • Abandonner l'injection de dépendances : chaque fois qu'un Bean de portée singleton a besoin d'un Bean de portée prototype, il demande activement une nouvelle instance de Bean au conteneur, garantissant ainsi que chaqueprototype Beaninstance injectée est l'instance la plus récente.
  • Utiliser l'injection de méthode : l'injection de méthode utilise généralement l'injection de méthode lookup. L'injection de méthode lookup permet au conteneur Spring de remplacer les méthodes abstraites ou concrètes des Beans dans le conteneur, en renvoyant le résultat de la recherche d'autres Beans dans le conteneur. Le Bean recherché est généralement unnon-singleton Bean. Spring répond à l'exigence ci-dessus en utilisant des proxys dynamiques JDK ou la bibliothèque cglib pour modifier le code binaire du client.

Il est recommandé d'utiliser la deuxième méthode, l'injection de méthode. Pour utiliser l'injection de méthode lookup, il faut en gros suivre les deux étapes suivantes :

  1. Définir la classe d'implémentation du Bean appelant comme une classe abstraite, et définir une méthode abstraite pour obtenir le Bean dont il dépend.
  2. Dans<bean.../>Ajoutez le<lookup-method.../>élément enfant à l'élément, en laissant Spring implémenter la méthode abstraite spécifiée pour la classe d'implémentation du Bean appelant.

Remarque :

Spring utilisera l'amélioration dynamique à l'exécution pour implémenter la<lookup-method.../>méthode abstraite spécifiée par l'élément. Si la classe abstraite cible a implémenté une interface, Spring utilisera le proxy dynamique JDK pour implémenter la classe abstraite et implémentera la méthode abstraite pour celle-ci ; si la classe abstraite cible n'a pas implémenté d'interface, Spring utilisera cglib pour implémenter la classe abstraite et implémentera la méthode abstraite pour celle-ci. La bibliothèque cglib a déjà été intégrée au paquet spring-core-xxx.jar dans Spring 4.0.

Deux types de post-processeurs

Spring fournit deux post-processeurs couramment utilisés :

  • Post-processeur de Bean : ce post-processeur effectue un post-traitement sur les Beans dans le conteneur, fournissant une amélioration supplémentaire aux Beans.
  • Post-processeur de conteneur : ce post-processeur effectue un post-traitement sur le conteneur IoC afin d'améliorer les fonctionnalités du conteneur.

Post-processeur de Bean

Un post-processeur de Bean est un type spécial de Bean. Ce Bean spécial ne fournit pas de services à l'extérieur, et il peut même omettre l'attribut id. Il est principalement responsable d'effectuer un post-traitement sur d'autres Beans dans le conteneur, comme générer des proxys pour les Beans cibles dans le conteneur. Ce type de Bean est appelé post-processeur de Bean. Après qu'une instance de Bean a été créée avec succès, le post-processeur de Bean effectue un traitement d'amélioration supplémentaire sur l'instance de Bean. Un post-processeur de Bean doit implémenter l'BeanPostProcessorinterface, et doit implémenter les deux méthodes de cette interface.

  1. Object postProcessBeforeInitialization(Object bean, String name) throws BeansException: Le premier paramètre de cette méthode est l'instance de Bean sur le point d'être post-traitée par le système, et le second paramètre est l'id de configuration du Bean.
  2. Object postProcessAfterinitialization(Object bean, String name) throws BeansException: Le premier paramètre de cette méthode est l'instance de Bean sur le point d'être post-traitée par le système, et le second paramètre est l'id de configuration du Bean.

Une fois qu'un post-processeur de Bean est enregistré dans le conteneur, il démarre automatiquement et fonctionne automatiquement lors de la création de chaque Bean dans le conteneur. Le moment de rappel des deux méthodes du post-processeur de Bean est illustré dans la figure suivante :

bean-post-process

Notez que si vous utilisezBeanFactorycomme conteneur Spring, vous devez enregistrer manuellement le post-processeur de Bean. Le programme doit obtenir une instance de post-processeur de Bean, puis l'enregistrer manuellement.

BeanPostProcessor bp = (BeanPostProcessor)beanFactory.getBean("bp");
beanFactory.addBeanPostProcessor(bp);
Person p = (Person)beanFactory.getBean("person");

Post-processeur de conteneur

Le post-processeur de Bean est responsable du traitement de toutes les instances de Bean dans le conteneur, tandis que le post-processeur de conteneur est responsable du traitement du conteneur lui-même. Le post-processeur de conteneur doit implémenter l'BeanFactoryPostProcessorinterface, et implémenter une méthode de l'interface.postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory)Le corps de méthode qui implémente cette méthode est le traitement effectué sur le conteneur Spring. Ce traitement peut être une extension personnalisée du conteneur Spring ou, bien sûr, ne pas effectuer de traitement du tout sur le conteneur Spring.

similaire àBeanPostProcessor，ApplicationContextIl peut détecter automatiquement les post-processeurs de conteneur dans le conteneur et enregistrer automatiquement les post-processeurs de conteneur. Mais si vous utilisezBeanFactoryEn tant que conteneur Spring, il doit appeler manuellement ce post-processeur de conteneur pour le traitement.BeanFactoryconteneur.

Prise en charge de la « configuration zéro » de Spring

Recherche de classes de Bean

Spring fournit les annotations suivantes pour marquer les Beans Spring :

  • @Component: Marque une classe de bean Spring ordinaire.
  • @Controller: Annote une classe de composant contrôleur.
  • @Service: Annote une classe de composant de logique métier.
  • @Repository: Annote une classe de composant DAO.

Effectuez la configuration suivante dans le fichier de configuration Spring pour spécifier le package à analyser automatiquement :

<context:component-scan base-package="edu.shu.spring.domain"/>

Configuration des dépendances avec @Resource

@ResourceSitué àjavax.annotationSitué sous le package, il est issu de la spécification JavaEE.Annotation, Spring a directement emprunté ceciAnnotation, en utilisant ceciAnnotationSpécifiez des Beans collaborateurs pour le Bean cible. Utilisez@Resourceet<property.../>L'attribut ref de l'élément a le même effet.
@Resourcepeut non seulement annoter les méthodes setter, mais aussi annoter directement les variables d'instance. Si vous utilisez@ResourceAnnoter des variables d'instance sera encore plus simple ; dans ce cas, Spring utilisera directement l'injection de champ standard de JavaEE, et même les méthodes setter ne sont pas nécessaires.

Personnaliser le comportement du cycle de vie avec @PostConstruct et @PreDestroy

@PostConstructet@PreDestroyÉgalement situées dans le package javax.annotation, ce sont deux annotations de la spécification JavaEE. Spring les a directement empruntées pour personnaliser le comportement du cycle de vie des Beans dans le conteneur Spring. Toutes deux servent à modifier des méthodes et ne nécessitent aucun attribut. La méthode modifiée par la première est la méthode d'initialisation du Bean ; la méthode modifiée par la seconde est la méthode exécutée avant que le Bean ne soit détruit.

Injection automatique améliorée et câblage précis dans Spring 4.0

Spring fournit@Autowiredl'annotation pour spécifier l'injection automatique,@Autowiredpeut annoter des méthodes setter, des méthodes ordinaires, des variables d'instance, des constructeurs, etc. Lors de l'utilisation de@AutowiredLorsqu'on annote une méthode setter, la stratégie d'injection automatique byType est adoptée par défaut. Avec cette stratégie, il y a souvent plusieurs instances de bean candidates correspondant au type d'injection automatique, ce qui peut provoquer des exceptions. Pour obtenir une injection automatique précise, Spring fournit@Qualifierl'annotation, en utilisant@Qualifier, permet d'effectuer un assemblage automatique en fonction de l'id du Bean.

L'AOP de Spring

Pourquoi l'AOP est nécessaire

AOP (Programmation orientée aspect), également appelée programmation orientée aspect, en complément de la programmation orientée objet, est devenue une approche de programmation relativement mature. En fait, l'AOP n'existe pas depuis très longtemps. L'AOP et la POO se complètent ; la programmation orientée aspect décompose le processus d'exécution du programme en divers aspects.

L'AOP est spécifiquement utilisée pour gérer les préoccupations transversales réparties dans divers modules (différentes méthodes) d'un système. Dans les applications JavaEE, l'AOP est souvent utilisée pour gérer des services au niveau du système présentant des caractéristiques transversales, tels que la gestion des transactions, les contrôles de sécurité, la mise en cache et la gestion des pools d'objets. L'AOP est devenue une solution très courante.

Implémentation de l'AOP avec AspectJ

AspectJ est un framework AOP basé sur le langage Java, offrant de puissantes fonctionnalités AOP. De nombreux autres frameworks AOP ont emprunté ou adopté certaines de ses idées. Il se compose principalement de deux parties : une partie définit la spécification syntaxique pour exprimer et définir la programmation AOP. Avec cette spécification syntaxique, l'AOP peut facilement résoudre les préoccupations transversales dans le langage Java ; l'autre partie est la partie outillage, comprenant des outils de compilation et de débogage, etc.

Les implémentations de l'AOP peuvent être divisées en deux catégories :

  1. Implémentation statique de l'AOP : le framework AOP modifie le programme pendant la phase de compilation, c'est-à-dire qu'il enrichit la classe cible et génère une classe proxy AOP statique, représentée par AspectJ.
  2. Implémentation dynamique de l'AOP : le framework AOP génère dynamiquement des proxys AOP au moment de l'exécution pour enrichir les objets cibles, représentée par Spring AOP.

De manière générale, l'implémentation statique de l'AOP offre de meilleures performances, mais nécessite un compilateur spécial. L'implémentation dynamique de l'AOP est une implémentation Java pure, elle ne nécessite donc pas de compilateur spécial, mais ses performances sont généralement légèrement moins bonnes.

Concepts de base de l'AOP

Quelques termes concernant la programmation orientée aspect :

  • Aspect : Un aspect est utilisé pour organiser plusieurs Advice, et Advice est défini dans l'aspect.
  • Joinpoint : Un point précis pendant l'exécution du programme, tel qu'un appel de méthode ou un lancement d'exception. Dans Spring AOP, un joinpoint est toujours un appel de méthode.
  • Advice : Traitement amélioré exécuté par le framework AOP à des pointcuts spécifiques. Le traitement possède des types tels que « around », « before » et « after ».
  • Pointcut : Un joinpoint où un traitement amélioré peut être inséré. En bref, lorsqu'un joinpoint répond à des exigences spécifiées, un traitement amélioré sera ajouté à ce joinpoint, et ce joinpoint devient un pointcut.

Prise en charge de l'AOP par Spring

Les proxies AOP dans Spring sont générés et gérés par le conteneur IoC de Spring, et leurs dépendances sont également gérées par le conteneur IoC.
Afin de l'utiliser dans l'application@AspectJPour le prendre en charge, Spring doit ajouter trois bibliothèques :

  • aspectjweaver.jar
  • aspectjrt.jar
  • aopalliance.jar

Et effectuer la configuration suivante dans le fichier de configuration Spring :

<!--启动@AspectJ支持-->
<aop:aspectj-autoproxy/>

<!--指定自动搜索Bean组件、自动搜索切面类-->
<context:component-scan base-package="edu.shu.sprint.service">
    <context:include-filter type="annotation" expression="org.aspectj.lang.annotation.Aspect"/>
</context:component-scan>

Source : http://codepub.cn/2015/06/21/Basic-knowledge-summary-of-Spring/