Frühling AOP vs AspectJ

Ich habe den Eindruck, dass Spring AOP am besten für anwendungsspezifische Aufgaben wie Sicherheit, Protokollierung, Transaktionen usw. verwendet wird, da benutzerdefinierte Java5-Annotationen als Framework verwendet werden. AspectJ scheint jedoch in Bezug auf Designmuster freundlicher zu sein.

Kann jemand die verschiedenen Vor- und Nachteile der Verwendung von Spring AOP vs AspectJ in einer Spring-Anwendung hervorheben?

Spring-AOP-Profis

• Die Verwendung ist einfacher als bei AspectJ, da Sie weder LTW ( Load-Time Weaving ) noch den AspectJ-Compiler verwenden müssen.

• Es werden das Proxy-Muster und das Decorator-Muster verwendet

Spring-AOP Cons

• Dies ist ein Proxy-basiertes AOP, sodass Sie grundsätzlich nur Joinpoints für die Methodenausführung verwenden können.
• Aspekte werden nicht angewendet, wenn eine andere Methode innerhalb derselben Klasse aufgerufen wird.
• Es kann ein wenig Laufzeitaufwand geben.
• Spring-AOP kann nichts hinzufügen, was nicht von der Spring-Fabrik erstellt wurde

AspectJ Pros

• Dies unterstützt alle Joinpoints. Dies bedeutet, dass Sie alles tun können.
• Es gibt weniger Laufzeitaufwand als bei Spring AOP.

AspectJ Cons

• Achtung. Überprüfen Sie, ob Ihre Aspekte nur so gewebt sind, wie Sie gewebt werden möchten.
• Sie benötigen einen zusätzlichen Erstellungsprozess mit AspectJ Compiler oder müssen LTW (Load-Time Weaving) einrichten.

Abgesehen von dem, was andere gesagt haben - nur um es neu zu formulieren there are two major differences:

1. Einer hängt mit der Art des Webens zusammen.
2. Ein weiterer zur Joinpoint-Definition.

Spring-AOP: Laufzeitweben durch Proxy mit dem Konzept vondynamic proxy if interface exists or cglib library if direct implementation provided.

AspektJ: Kompilierungszeit, AspectJ Java Tools(ajc compiler)wenn die Quelle verfügbar ist, oder Weben nach der Kompilierung (unter Verwendung kompilierter Dateien). Außerdem kann das Weben der Ladezeit mit Spring aktiviert werden - es benötigt die aspectjDefinitionsdatei und bietet Flexibilität.

Das Weben während der Kompilierung kann (in einigen Fällen) Vorteile der Leistung und auch der Leistung bieten joinpoint definition in Spring-aop is restricted to method definition only which is not the case for AspectJ.

Ein zusätzlicher Hinweis: Wenn die Leistung unter hoher Last wichtig ist, sollten Sie AspectJ verwenden, das 9-35x schneller als Spring AOP ist . 10ns vs 355ns klingen vielleicht nicht nach viel, aber ich habe Leute gesehen, die VIELE Aspekte verwendet haben. Aspekte im Wert von 10K. In diesen Fällen kann Ihre Anfrage Tausende von Aspekten betreffen. In diesem Fall fügen Sie dieser Anforderung ms hinzu.

Siehe die Benchmarks .

Das Benutzerhandbuch für die Feder enthält viele Informationen direkt aus dem Maul des Pferdes.

Das Kapitel 6.4 - Auswählen des zu verwendenden AOP-Deklarationsstils ist für Sie nicht mehr aktuell, da hier die Vor- und Nachteile beider erläutert werden.

Der Absatz 6.1.2 - Frühling AOP Capabilites und Ziele & Kapitel 6.2 - @Aspect Unterstützung und 6.8 - Verwendung von AspectJ mit Frühlings - Anwendungen sollte particularily interessant sein.

Feder AOP ist einer der wesentlichen Bestandteile des Federgerüsts. In der Grundphase basiert das Federgerüst auf IoC und AOP. Im offiziellen Frühlingsverlauf gibt es eine Folie, auf der steht:

Das AOP ist einer der wichtigsten Teile des Frameworks.

Der entscheidende Punkt für das Verständnis der Funktionsweise von AOP in Spring ist, dass wir beim Schreiben eines Aspekts mit Spring das Framework mit dem JDKDynamicProxyErstellen eines Proxys für Ihre Objekte instrumentieren, mit einer, wenn Ihre Bean eine Schnittstelle implementiert, oder über CGLIB, wenn Ihre Bean keine implementiert Schnittstelle. Denken Sie daran, dass Sie cglib 2.2 in Ihrem Klassenpfad haben müssen, wenn Sie Spring vor Version 3.2 verwenden. Ab Spring 3.2 ist es nutzlos, da cglib 2.2 im Kern enthalten war.

Das Framework bei der Bean-Erstellung erstellt einen Proxy, der Ihre Objekte umschließt und Querschnittsthemen wie Sicherheit, Transaktionsmanagement, Protokollierung usw. hinzufügt.

Die Proxy-Erstellung auf diese Weise wird beginnend mit einem Pointcut-Ausdruck angewendet, der das Framework instrumentiert, um zu entscheiden, welche Beans und Methoden als Proxys erstellt werden. Der Rat ist mehr verantwortlich als für Ihren Code. Denken Sie daran, dass der Pointcut in diesem Prozess nur öffentliche Methoden erfasst, die nicht als endgültig deklariert sind.

Während in Spring AOP das Weben von Aspekten vom Container beim Start des Containers ausgeführt wird, müssen Sie dies in AspectJ mit einer Nachkompilierung Ihres Codes durch Bytecode-Änderung durchführen. Aus diesem Grund ist der Spring-Ansatz meiner Meinung nach einfacher und überschaubarer als AspectJ.

Auf der anderen Seite können Sie mit dem Spring AOP nicht die gesamte Leistung von AOP nutzen, da die Implementierung über Proxys und nicht durch Änderung Ihres Codes erfolgt.

Wie in AspectJ können Sie in SpringAOP das Weben mit Ladezeit verwenden. Sie können von dieser Funktion profitieren, die im Frühjahr mit einem Agenten und speziellen Konfigurationen @EnabledLoadWeavingoder in XML implementiert wird . Sie können den Namensraum als Beispiel verwenden. In Spring AOP können Sie jedoch nicht alle Fälle abfangen. Beispielsweise wird der newBefehl in Spring AOP nicht unterstützt.

In Spring AOP können Sie jedoch von der Verwendung von AspectJ durch die Verwendung der aspectofFactory-Methode in der Spring Configuration Bean profitieren .

Aus dem Grund, dass Spring AOP im Grunde ein aus dem Container erstellter Proxy ist, können Sie AOP nur für Spring Beans verwenden. Während Sie mit AspectJ arbeiten, können Sie den Aspekt in all Ihren Bohnen verwenden. Ein weiterer Vergleichspunkt ist das Debuggen und die Vorhersagbarkeit des Codeverhaltens. Mit Spring AOP wird der Job vollständig vom Java-Compiler ausgeführt, und Aspekte sind eine sehr coole Möglichkeit, einen Proxy für Ihre Spring Bean zu erstellen. Wenn Sie in AspectJ den Code ändern, müssen Sie mehr kompilieren und verstehen, wo Ihre Aspekte verwoben sind, kann schwierig sein. Selbst das Herunterfahren des Webens im Frühjahr ist einfacher: Mit der Feder entfernen Sie den Aspekt aus Ihrer Konfiguration, starten neu und es funktioniert. In AspectJ müssen Sie den Code neu kompilieren!

Beim Weben während der Ladezeit ist AspectJ flexibler als Spring, da Spring nicht alle Optionen von AspectJ unterstützt. Aber meiner Meinung nach Wenn Sie den Erstellungsprozess einer Bean ändern möchten, ist es besser, die benutzerdefinierte Anmeldung in einer Fabrik zu verwalten und nicht mit dem Laden eines Aspekts, der das Verhalten Ihres neuen Bedieners ändert.

Ich hoffe, dass dieses Panorama von AspectJ und Spring AOP Ihnen hilft, den Unterschied zwischen den beiden Tränken zu verstehen

Es ist wichtig zu prüfen, ob Ihre Aspekte geschäftskritisch sind und wo Ihr Code bereitgestellt wird. Spring AOP bedeutet, dass Sie sich auf das Weben während der Ladezeit verlassen. Dies kann fehlschlagen und hat meiner Erfahrung nach dazu geführt, dass möglicherweise protokollierte Fehler vorliegen, die Anwendung jedoch nicht ohne Aspektcode ausgeführt werden kann. [Ich möchte den Vorbehalt hinzufügen, dass es möglich sein kann, sie so zu konfigurieren, dass dies nicht der Fall ist Fall; aber ich persönlich bin mir dessen nicht bewusst ]. Das Weben während der Kompilierung vermeidet dies.

Wenn Sie AspectJ in Verbindung mit dem Aspektj-Maven-Plugin verwenden, können Sie außerdem Unit-Tests für Ihre Aspekte in einer CI-Umgebung durchführen und darauf vertrauen, dass erstellte Artefakte getestet und korrekt gewebt werden. Obwohl Sie sicherlich federgesteuerte Komponententests schreiben können, können Sie dennoch nicht garantieren, dass der bereitgestellte Code derjenige ist, der getestet wurde, wenn LTW fehlschlägt.

Eine weitere Überlegung ist, ob Sie die Anwendung in einer Umgebung hosten, in der Sie den Erfolg oder Misserfolg eines Server- / Anwendungsstarts direkt überwachen können, oder ob Ihre Anwendung in einer Umgebung bereitgestellt wird, in der sie nicht unter Ihrer Aufsicht steht [z. B. in der sie sich befindet wird von einem Client gehostet]. Dies würde wiederum den Weg zum Kompilieren des Zeitwebens weisen.

Vor fünf Jahren war ich viel mehr für Spring konfiguriertes AOP aus dem einfachen Grund, dass es einfacher war, damit zu arbeiten und meine IDE weniger wahrscheinlich zu zerkauen. Mit zunehmender Rechenleistung und verfügbarem Speicher ist dies jedoch weniger ein Problem geworden, und CTW mit dem Aspekt-Javen-Plugin ist aus den oben genannten Gründen eine bessere Wahl in meiner Arbeitsumgebung geworden.

Dieser Artikel enthält auch eine gute Erklärung zum Thema.

Spring AOP und AspectJ haben unterschiedliche Ziele.

Spring AOP zielt darauf ab, eine einfache AOP-Implementierung in Spring IoC bereitzustellen, um die häufigsten Probleme zu lösen, mit denen Programmierer konfrontiert sind.

Andererseits ist AspectJ die ursprüngliche AOP-Technologie, die darauf abzielt, eine vollständige AOP-Lösung bereitzustellen.

Im Vergleich zu AOP muss AspectJ die Zielklasse zur Kompilierungszeit nicht erweitern. Stattdessen wird zur Laufzeit eine Proxy-Klasse für die Zielklasse generiert, die entweder dieselbe Schnittstelle wie die Zielklasse implementiert oder eine Unterklasse der Zielklasse ist.

Zusammenfassend kann eine Instanz einer Proxy-Klasse als Instanz einer Zielklasse verwendet werden. Im Allgemeinen ist das zur Kompilierungszeit erweiterte AOP-Framework hinsichtlich der Leistung vorteilhafter, da das zur Laufzeit erweiterte AOP-Framework bei jeder Ausführung dynamische Verbesserungen erfordert.