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