Vergleich von Spring AOP und AspectJ
1. Einführung
Heutzutage gibt es mehrere verfügbare AOP-Bibliotheken, die eine Reihe von Fragen beantworten müssen:
-
Ist es mit meiner bestehenden oder neuen Anwendung kompatibel?
-
Wo kann ich AOP implementieren?
-
Wie schnell lässt es sich in meine Anwendung integrieren?
-
Was ist der Leistungsaufwand?
In diesem Artikel werden wir uns mit der Beantwortung dieser Fragen befassen und Spring AOP und AspectJ vorstellen - die beiden beliebtesten AOP-Frameworks für Java.
2. AOP-Konzepte
Bevor wir beginnen, lassen Sie uns einen kurzen Überblick über Begriffe und Kernkonzepte auf hoher Ebene geben:
-
Aspekt - ** Ein Standardcode / eine Standardfunktion, die über mehrere Stellen in der Anwendung verteilt ist und sich in der Regel von der tatsächlichen Geschäftslogik unterscheidet (z. B. Transaktionsverwaltung). Jeder Aspekt konzentriert sich auf eine bestimmte Querschnittsfunktion
-
Joinpoint - ** Dies ist ein bestimmter Punkt während der Ausführung von Programmen wie Methodenausführung, Konstruktoraufruf oder Feldzuweisung
-
Beratung - die Aktion, die der Aspekt in einem bestimmten Joinpoint ausführt
-
Pointcut - ein regulärer Ausdruck, der einem Joinpoint entspricht. Jedes Mal, wenn ein Join-Punkt mit einem Pointcut übereinstimmt, wird ein mit diesem Pointcut verknüpfter bestimmter Hinweis ausgeführt
-
Weben - der Prozess der Verknüpfung von Aspekten mit Zielobjekten, um ein empfohlenes Objekt zu erstellen
3. Frühling AOP und AspektJ
Lassen Sie uns nun Spring AOP und AspectJ auf einer Reihe von Achsen diskutieren - wie z. B. Fähigkeiten, Ziele, Webart, interne Struktur, Verbindungspunkte und Einfachheit.
3.1. Fähigkeiten und Ziele
Einfach ausgedrückt haben Spring AOP und AspectJ unterschiedliche Ziele.
Spring AOP zielt darauf ab, eine einfache AOP-Implementierung für Spring IoC bereitzustellen, um die häufigsten Probleme zu lösen, mit denen Programmierer konfrontiert sind. It is not intended as a complete AOP solution - kann nur auf Beans angewendet werden, die von einem Spring-Container verwaltet werden.
AndererseitsAspectJ is the original AOP technology which aims to provide complete AOP solution. Es ist robuster, aber auch wesentlich komplizierter als Spring AOP. Es ist auch erwähnenswert, dass AspectJ auf alle Domänenobjekte angewendet werden kann.
3.2. Weberei
Sowohl AspectJ als auch Spring AOP verwenden die verschiedenen Webarten, die sich auf ihr Verhalten in Bezug auf Leistung und Benutzerfreundlichkeit auswirken.
AspectJ verwendet drei verschiedene Webarten:
-
Compile-time weaving: Der AspectJ-Compiler verwendet sowohl den Quellcode unseres Aspekts als auch unserer Anwendung als Eingabe und erstellt als Ausgabe gewebte Klassendateien
-
Post-compile weaving: Dies wird auch als binäres Weben bezeichnet. Es wird verwendet, um vorhandene Klassendateien und JAR-Dateien mit unseren Aspekten zu weben
-
Load-time weaving: Dies ist genau wie beim früheren binären Weben, mit dem Unterschied, dass das Weben verschoben wird, bis ein Klassenladeprogramm die Klassendateien in die JVM lädt
Ausführlichere Informationen zu AspectJ selbst finden Sie unterhead on over to this article.
Da AspectJ das Weben von Kompilierungszeit und Klassenladezeit verwendet,Spring AOP makes use of runtime weaving.
Beim Runtime-Weben werden die Aspekte während der Ausführung der Anwendung mithilfe von Proxys des Zielobjekts gewebt - entweder mithilfe des dynamischen JDK-Proxys oder des CGLIB-Proxys (die im nächsten Punkt erläutert werden):
3.3. Interne Struktur und Anwendung
Spring AOP ist ein Proxy-basiertes AOP-Framework. Dies bedeutet, dass zum Implementieren von Aspekten für die Zielobjekte Proxys dieses Objekts erstellt werden. Dies wird auf zwei Arten erreicht:
-
JDK Dynamic Proxy - der bevorzugte Weg für Spring AOP. Wenn das Zielobjekt auch nur eine Schnittstelle implementiert, wird der dynamische JDK-Proxy verwendet
-
CGLIB-Proxy - Wenn das Zielobjekt keine Schnittstelle implementiert, kann der CGLIB-Proxy verwendet werden
Weitere Informationen zu Spring AOP-Proxy-Mechanismen finden Sie unterthe official docs.
AspectJ hingegen führt zur Laufzeit nichts aus, da die Klassen direkt mit Aspekten kompiliert werden.
Im Gegensatz zu Spring AOP sind daher keine Entwurfsmuster erforderlich. Um die Aspekte des Codes zu verweben, wird der Compiler AspectJ Compiler (ajc) eingeführt, über den wir unser Programm kompilieren und dann ausführen, indem wir eine kleine Laufzeitbibliothek (<100 KB) bereitstellen.
3.4. Joinpoints
In Abschnitt 3.3 haben wir gezeigt, dass Spring AOP auf Proxy-Mustern basiert. Aus diesem Grund muss es die anvisierte Java-Klasse in Unterklassen unterteilen und die übergreifenden Bedenken entsprechend berücksichtigen.
Aber es ist mit einer Einschränkung verbunden. 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.
Gleiches gilt für statische und endgültige Methoden. Frühlingsaspekte können nicht auf sie angewendet werden, da sie nicht überschrieben werden können. Aufgrund dieser Einschränkungen unterstützt Spring AOP daher nur Join-Punkte für die Methodenausführung.
AspectJ weaves the cross-cutting concerns directly into the actual code before runtime. Im Gegensatz zu Spring AOP muss das Zielobjekt jedoch nicht in Unterklassen unterteilt werden, und es werden daher auch viele andere Joinpoints unterstützt. Es folgt eine Zusammenfassung der unterstützten Joinpunkte:
| Joinpoint | Spring AOP unterstützt | AspectJ unterstützt |
|---|---|---|
Methodenaufruf |
No |
Yes |
Methodenausführung |
Yes |
Yes |
Konstruktoraufruf |
No |
Yes |
Konstruktorausführung |
No |
Yes |
Statische Initialisierungsausführung |
No |
Yes |
Objektinitialisierung |
No |
Yes |
Feldreferenz |
No |
Yes |
Feldzuordnung |
No |
Yes |
Handler-Ausführung |
No |
Yes |
Beratung Ausführung |
No |
Yes |
Es ist auch erwähnenswert, dass in Spring AOP Aspekte nicht auf die Methode angewendet werden, die innerhalb derselben Klasse aufgerufen wird.
Dies liegt natürlich daran, dass wir beim Aufrufen einer Methode innerhalb derselben Klasse nicht die Methode des von Spring AOP bereitgestellten Proxys aufrufen. Wenn wir diese Funktionalität benötigen, müssen wir eine separate Methode in verschiedenen Beans definieren oder AspectJ verwenden.
3.5. Einfachheit
Spring AOP ist offensichtlich einfacher, da zwischen unserem Erstellungsprozess kein zusätzlicher Compiler oder Weber eingeführt wird. Es verwendet das Runtime-Weben und fügt sich daher nahtlos in unseren üblichen Erstellungsprozess ein. Obwohl es einfach aussieht, funktioniert es nur mit Beans, die von Spring verwaltet werden.
Um AspectJ verwenden zu können, müssen wir jedoch den AspectJ-Compiler (ajc) einführen und alle unsere Bibliotheken neu verpacken (es sei denn, wir wechseln zum Weben nach dem Kompilieren oder zum Laden während der Ladezeit).
Dies ist natürlich komplizierter als das vorherige - denn es führt die AspectJ Java Tools ein (die einen Compiler (ajc), einen Debugger (ajdb), einen Dokumentationsgenerator (ajdoc) und einen Programmstruktur-Browser (ajbrowser) enthalten), die wir verwenden müssen entweder in unsere IDE oder das Build-Tool integriert werden.
3.6. Performance
In Bezug auf die Leistungcompile-time weaving is much faster than runtime weaving. Spring AOP ist ein proxybasiertes Framework, sodass zum Zeitpunkt des Anwendungsstarts Proxys erstellt werden. Außerdem gibt es einige weitere Methodenaufrufe pro Aspekt, die sich negativ auf die Leistung auswirken.
Andererseits verwebt AspectJ die Aspekte vor der Ausführung der Anwendung in den Hauptcode, sodass im Gegensatz zu Spring AOP kein zusätzlicher Laufzeitaufwand entsteht.
Aus diesen Gründen deuten diebenchmarksdarauf hin, dass AspectJ fast 8- bis 35-mal schneller ist als Spring AOP.
4. Zusammenfassung
Diese kurze Tabelle fasst die wichtigsten Unterschiede zwischen Spring AOP und AspectJ zusammen:
| Frühling AOP | AspektJ |
|---|---|
In reinem Java implementiert |
Implementiert mit Erweiterungen der Programmiersprache Java |
Kein separater Kompilierungsprozess erforderlich |
Benötigt AspectJ-Compiler (ajc), sofern LTW nicht eingerichtet ist |
Es ist nur Laufzeitweben verfügbar |
Laufzeitweberei ist nicht verfügbar. Unterstützt das Weben während der Kompilierung, nach der Kompilierung und beim Laden |
Weniger leistungsfähig - unterstützt nur das Weben auf Methodenebene |
Leistungsstärker - kann Felder, Methoden, Konstruktoren, statische Initialisierer, endgültige Klassen / Methoden usw. weben. |
Kann nur auf Beans implementiert werden, die von Spring Container verwaltet werden |
Kann auf allen Domänenobjekten implementiert werden |
Unterstützt nur Pointcuts für die Methodenausführung |
Unterstützt alle Pointcuts |
Proxys werden aus Zielobjekten erstellt, und Aspekte werden auf diese Proxys angewendet |
Aspekte werden direkt in Code verwoben, bevor die Anwendung ausgeführt wird (vor der Laufzeit). |
Viel langsamer als AspectJ |
Bessere Leistung |
Einfach zu erlernen und anzuwenden |
Vergleichsweise komplizierter als Spring AOP |
5. Auswahl des richtigen Frameworks
Wenn wir alle in diesem Abschnitt vorgebrachten Argumente analysieren, werden wir verstehen, dass ein Framework überhaupt nicht besser ist als ein anderes.
Einfach ausgedrückt, hängt die Auswahl stark von unseren Anforderungen ab:
-
Framework: Wenn die Anwendung kein Spring-Framework verwendet, haben wir keine andere Wahl, als die Idee der Verwendung von Spring AOP fallen zu lassen, da nichts verwaltet werden kann, was außerhalb der Reichweite des Spring-Containers liegt. Wenn unsere Anwendung jedoch vollständig mit dem Spring Framework erstellt wird, können wir Spring AOP verwenden, da es einfach zu erlernen und anzuwenden ist
-
Flexibilität: Aufgrund der eingeschränkten Unterstützung für Join Points ist Spring AOP keine vollständige AOP-Lösung, sondern löst die häufigsten Probleme, mit denen Programmierer konfrontiert sind. Wenn wir AOP vertiefen und maximal ausnutzen möchten und die Unterstützung von einer Vielzahl verfügbarer Joinpoints wünschen, ist AspectJ die richtige Wahl
-
Leistung: Wenn wir begrenzte Aspekte verwenden, gibt es geringfügige Leistungsunterschiede. Es gibt jedoch manchmal Fälle, in denen eine Anwendung mehr als Zehntausende von Aspekten aufweist. In solchen Fällen möchten wir kein Laufzeitweben verwenden, daher ist es besser, sich für AspectJ zu entscheiden. Es ist bekannt, dass AspectJ 8- bis 35-mal schneller ist als Spring AOP
-
Best of Both: Beide Frameworks sind vollständig miteinander kompatibel. Wir können Spring AOP immer nutzen, wann immer dies möglich ist, und AspectJ weiterhin verwenden, um Unterstützung für Joinpoints zu erhalten, die von ersteren nicht unterstützt werden
6. Fazit
In diesem Artikel haben wir sowohl Spring AOP als auch AspectJ in mehreren Schlüsselbereichen analysiert.
Wir haben die beiden Ansätze für AOP sowohl in Bezug auf die Flexibilität als auch in Bezug darauf verglichen, wie einfach sie in unsere Anwendung passen.