TOC

Comparaison des printemps AOP et AspectJ

Comparaison des printemps AOP et AspectJ

1. introduction

Il existe plusieurs bibliothèques AOP disponibles aujourd'hui, et celles-ci doivent pouvoir répondre à un certain nombre de questions:

  • Est-ce compatible avec mon application existante ou nouvelle?

  • Où puis-je mettre en œuvre AOP?

  • Combien de temps cela va-t-il intégrer à mon application?

  • Quel est le coût de la performance?

Dans cet article, nous allons chercher à répondre à ces questions et présenter Spring AOP et AspectJ, les deux frameworks AOP les plus populaires pour Java.

2. Concepts AOP

Avant de commencer, examinons rapidement les termes et les concepts de base:

  • Aspect - ** code / fonction standard dispersé sur plusieurs emplacements de l'application et généralement différent de la logique applicative réelle (par exemple, Gestion des transactions). Chaque aspect se concentre sur une fonctionnalité transversale spécifique

  • Joinpoint - ** il s'agit d'un point particulier lors de l'exécution de programmes tels que l'exécution de méthode, l'appel de constructeur ou l'affectation de champ

  • Conseil - l'action prise par l'aspect dans un point de jonction spécifique

  • Pointcut - une expression régulière qui correspond à un point de jonction. Chaque fois qu'un point de jonction correspond à un point coupé, un avis spécifié associé à ce pointtout est exécuté

  • Tissage - processus de liaison des aspects avec des objets ciblés pour créer un objet conseillé

3. Spring AOP et AspectJ

Parlons maintenant de Spring AOP et AspectJ sur plusieurs axes, tels que les capacités, les objectifs, le tissage, la structure interne, les points de jonction et la simplicité.

3.1. Capacités et objectifs

En termes simples, Spring AOP et AspectJ ont des objectifs différents.

Spring AOP vise à fournir une implémentation AOP simple dans Spring IoC afin de résoudre les problèmes les plus courants rencontrés par les programmeurs. It is not intended as a complete AOP solution - il ne peut être appliqué qu'aux beans gérés par un conteneur Spring.

D'autre part,AspectJ is the original AOP technology which aims to provide complete AOP solution. Il est plus robuste mais aussi nettement plus compliqué que Spring AOP. Il convient également de noter qu'AspectJ peut être appliqué à tous les objets du domaine.

3.2. Tissage

AspectJ et Spring AOP utilisent tous deux un type de tissage différent, ce qui a une incidence sur leur comportement en matière de performances et de facilité d'utilisation.

AspectJ utilise trois types de tissage différents:

  1. Compile-time weaving: Le compilateur AspectJ prend en entrée à la fois le code source de notre aspect et de notre application et produit un fichier de classe tissé en sortie

  2. Post-compile weaving: Ceci est également connu sous le nom de tissage binaire. Il est utilisé pour tisser des fichiers de classe existants et des fichiers JAR avec nos aspects

  3. Load-time weaving: C'est exactement comme l'ancien tissage binaire, à la différence que le tissage est reporté jusqu'à ce qu'un chargeur de classe charge les fichiers de classe dans la JVM

Pour plus d'informations sur AspectJ lui-même,head on over to this article.

AspectJ utilise le temps de compilation et le temps de chargement des classes,Spring AOP makes use of runtime weaving.

Avec le tissage d'exécution, les aspects sont tissés lors de l'exécution de l'application à l'aide de serveurs proxy de l'objet ciblé, à l'aide du proxy dynamique JDK ou du proxy CGLIB (décrits au point suivant):

image

3.3. Structure interne et application

Spring AOP est un framework AOP basé sur un proxy. Cela signifie que pour implémenter des aspects sur les objets cibles, il créera des proxys de cet objet. Ceci est réalisé de deux manières:

  1. JDK Dynamic Proxy - le moyen privilégié pour Spring AOP. Chaque fois que l'objet ciblé implémente une seule interface, le proxy dynamique JDK sera utilisé

  2. Proxy CGLIB - si l'objet cible n'implémente pas d'interface, le proxy CGLIB peut être utilisé

Nous pouvons en apprendre plus sur les mécanismes de proxy Spring AOP à partir dethe official docs.

AspectJ, en revanche, ne fait rien au moment de l’exécution car les classes sont compilées directement avec les aspects.

Et donc, contrairement à Spring AOP, il ne nécessite aucun modèle de conception. Pour tisser les aspects du code, il introduit son compilateur appelé AspectJ compiler (ajc), à travers lequel nous compilons notre programme, puis l'exécutons en fournissant une petite bibliothèque d'exécution (<100K).

3.4. Joinpoints

Dans la section 3.3, nous avons montré que Spring AOP est basé sur des modèles de proxy. Pour cette raison, il doit sous-classer la classe Java ciblée et appliquer les problèmes transversaux en conséquence.

Mais cela vient avec une limitation. We cannot apply cross-cutting concerns (or aspects) across classes that are “final” because they cannot be overridden and thus it would result in a runtime exception.

Il en va de même pour les méthodes statiques et finales. Les aspects de ressort ne peuvent pas leur être appliqués car ils ne peuvent pas être remplacés. C'est pourquoi Spring AOP, en raison de ces limitations, ne prend en charge que les points de jonction d'exécution de méthode.

Cependant,AspectJ weaves the cross-cutting concerns directly into the actual code before runtime. Contrairement à Spring AOP, il n'a pas besoin de sous-classer l'objet ciblé et prend donc en charge de nombreux autres points de jointure. Voici le récapitulatif des points de jonction pris en charge:

Joinpoint Spring AOP pris en charge AspectJ pris en charge

Appel de méthode

No

Yes

Exécution de la méthode

Yes

Yes

Appel du constructeur

No

Yes

Exécution du constructeur

No

Yes

Exécution d'initialiseur statique

No

Yes

Initialisation d'objet

No

Yes

Référence de terrain

No

Yes

Affectation sur le terrain

No

Yes

Exécution du gestionnaire

No

Yes

Exécution des conseils

No

Yes

Il convient également de noter que dans Spring AOP, les aspects ne sont pas appliqués à la méthode appelée dans la même classe.

C’est évidemment parce que lorsque nous appelons une méthode dans la même classe, nous n’appelons pas la méthode du proxy fournie par Spring AOP. Si nous avons besoin de cette fonctionnalité, nous devons définir une méthode distincte dans différents beans ou utiliser AspectJ.

3.5. Simplicité

Spring AOP est évidemment plus simple car il n'introduit aucun compilateur ou tisseur supplémentaire entre notre processus de construction. Il utilise le tissage d'exécution et s'intègre donc parfaitement à notre processus de construction habituel. Bien que cela ait l'air simple, cela ne fonctionne qu'avec les haricots gérés par Spring.

Cependant, pour utiliser AspectJ, nous devons introduire le compilateur AspectJ (ajc) et reconditionner toutes nos bibliothèques (à moins que nous ne passions au tissage post-compilation ou au chargement).

C’est bien sûr plus compliqué que le premier, car il introduit AspectJ Java Tools (qui inclut un compilateur (ajc), un débogueur (ajdb), un générateur de documentation (ajdoc), un navigateur de structure de programme (ajbrowser)). besoin d'intégrer avec notre IDE ou l'outil de construction.

3.6. Performance

En ce qui concerne les performances,compile-time weaving is much faster than runtime weaving. Spring AOP est un framework basé sur un proxy, il y a donc création de proxy au moment du démarrage de l'application. De plus, il y a quelques invocations de méthodes supplémentaires par aspect, ce qui affecte négativement les performances.

D'un autre côté, AspectJ intègre les aspects dans le code principal avant que l'application ne s'exécute et il n'y a donc pas de surcharge d'exécution supplémentaire, contrairement à Spring AOP.

Pour ces raisons, lesbenchmarks suggèrent qu'AspectJ est presque 8 à 35 fois plus rapide que Spring AOP.

4. Sommaire

Ce tableau rapide résume les principales différences entre Spring AOP et AspectJ:

Printemps AOP AspectJ

Implémenté en Java pur

Implémenté à l'aide d'extensions du langage de programmation Java

Pas besoin de processus de compilation séparé

Nécessite le compilateur AspectJ (ajc) sauf si LTW est configuré

Seul le tissage d'exécution est disponible

Le tissage d'exécution n'est pas disponible. Prend en charge le tissage au moment de la compilation, de la post-compilation et du chargement

Moins puissant - prend uniquement en charge le tissage au niveau de la méthode

Plus puissant - peut tisser des champs, des méthodes, des constructeurs, des initialiseurs statiques, des classes / méthodes finales, etc.

Ne peut être implémenté que sur les beans gérés par le conteneur Spring

Peut être implémenté sur tous les objets du domaine

Prend en charge uniquement les pointcuts d'exécution de méthode

Soutenir tous les points

Des proxies sont créés à partir d'objets ciblés et des aspects sont appliqués sur ces proxies

Les aspects sont directement tissés dans le code avant l'exécution de l'application (avant l'exécution)

Beaucoup plus lent que AspectJ

Meilleure performance

Facile à apprendre et à appliquer

Comparativement plus compliqué que Spring AOP

5. Choisir le bon cadre

Si nous analysons tous les arguments avancés dans cette section, nous commencerons à comprendre que ce n’est pas du tout qu’un framework est meilleur qu’un autre.

En termes simples, le choix dépend fortement de nos exigences:

  • Framework: si l'application n'utilise pas le framework Spring, nous n'avons d'autre choix que d'abandonner l'idée d'utiliser Spring AOP car elle ne peut pas gérer tout ce qui est hors de portée du conteneur Spring. Cependant, si notre application est entièrement créée à l'aide du framework Spring, nous pouvons utiliser Spring AOP car il est simple à apprendre et à appliquer

  • Flexibilité: Compte tenu de la prise en charge limitée des points de jonction, Spring AOP n'est pas une solution AOP complète, mais il résout les problèmes les plus courants rencontrés par les programmeurs. Bien que si nous voulons aller plus loin et exploiter l'AOP au maximum de ses possibilités et si nous voulons le support d'un large éventail de points de jonction, alors AspectJ est le choix

  • Performances: si nous utilisons des aspects limités, les différences de performances sont insignifiantes. Mais il arrive parfois qu'une application comporte plus de dizaines de milliers d'aspects. Nous ne voudrions pas utiliser le tissage d'exécution dans de tels cas, il serait donc préférable d'opter pour AspectJ. AspectJ est connu pour être 8 à 35 fois plus rapide que Spring AOP

  • Meilleur des deux: ces deux cadres sont entièrement compatibles l'un avec l'autre. Nous pouvons toujours profiter de Spring AOP dans la mesure du possible et continuer à utiliser AspectJ pour obtenir la prise en charge des points de jonction qui ne sont pas pris en charge par l'ancien.

6. Conclusion

Dans cet article, nous avons analysé Spring AOP et AspectJ, dans plusieurs domaines clés.

Nous avons comparé les deux approches de l'AOP à la fois sur la flexibilité et sur la facilité avec laquelle elles s'intégreront à notre application.

Related