Spring AOP vs AspectJ

Profesjonaliści Spring-AOP

• Jest łatwiejszy w użyciu niż AspectJ, ponieważ nie musisz używać LTW ( czas ładowania) lub kompilator http://www.eclipse.org/aspectj ... .html AspectJ.
• Używa wzorca proxy i dekoratora szablon

Wady Spring-AOP

• To jest serwer proxy AOP, więc w zasadzie do wykonania metody można używać tylko punktów połączeń.
• Aspekty nie są stosowane podczas wywoływania innej metody w tej samej klasie.
• Może być trochę narzutu czasu realizacji.
• Spring-AOP nie może dodać aspektu do niczego, co nie zostało stworzone przez Spring Factory

AspectJ plus

• Obsługuje wszystkie punkty połączeń. Oznacza to, że możesz robić, co chcesz.
• Jest mniej czasu pracy niż Spring AOP.

AspectJ cons

• Bądź ostrożny. Sprawdź, czy Twoje aspekty są utkane tylko z tym, co chciałeś utkać.
• Potrzebujesz dodatkowego procesu kompilacji z kompilatorem AspectJ lub musisz dostosować LTW (czas ładowania).)

Oprócz tego, co powiedzieli inni - aby sparafrazować,

istnieją dwie główne różnice

:

• Jeden z nich jest związany z rodzajem tkactwa.
• Kolejnym jest zdefiniowanie punktu połączenia.

Spring-AOP:

środowisko uruchomieniowe przeplatania przez proxy przy użyciu koncepcji

dynamicznego proxy, jeśli interfejs istnieje, lub biblioteki cglib, jeśli zapewniono bezpośrednią implementację.

AspectJ:

tkanie w czasie kompilacji za pomocą

AspectJ Java Tools (kompilator ajc)

, jeśli źródło jest dostępne lub splatanie po kompilacji (przy użyciu skompilowanych plików). Możliwe jest również włączenie czasu rozruchu w Spring - wymaga to pliku definicji

aspektj

i zapewnia elastyczność.
Tkanie w czasie kompilacji może oferować korzyści w zakresie wydajności (w niektórych przypadkach), a definicja

punktu złączenia w Spring-aop jest ograniczona tylko do definicji metody, co nie ma miejsca w przypadku AspectJ.

Dodatkowa uwaga:

jeśli ważna jest wysoka wydajność obciążenia, będziesz potrzebować AspectJ, który będzie 9-35x szybszy niż Spring AOP
... 10ns w porównaniu z 355ns może nie brzmieć dużo, ale widziałem ludzi używających aspektów WIELE. 10 tysięcy jest wartych aspektów. W takich przypadkach Twoja prośba może dotyczyć tysięcy aspektów. W takim przypadku dodajesz ms do tego żądania.
Patrzeć na

kontrola
http://docs.codehaus.org/display/AW/AOP+Benchmark
wskaźniki.

Instrukcja wiosny
http://static.springsource.org ... .html
poda wiele informacji prosto z pyska konia.
Rozdział

6.4-Wybór stylu deklaracji AOP do użycia
http://static.springsource.org ... osing
jest dla ciebie martwa, gdy omawia zalety i wady obu.
Punkt powinien być szczególnie interesujący

6.1.2 - Wiosenne funkcje i cele AOP
http://static.springsource.org ... -defn
& amp; rozdziały

6.2 - Wsparcie @Aspect
http://static.springsource.org ... pectj
i

6.8 - Używanie AspectJ z aplikacjami Spring
http://static.springsource.org ... pectj
.

Spring AOP jest jedną z głównych części ramy sprężynowej. W najbardziej podstawowym stadium framework sprężynowy jest oparty na IoC i AOP. Oficjalny kurs wiosenny zawiera slajd, który mówi:

AOP jest jedną z najważniejszych części frameworka.

Kluczową kwestią do zrozumienia, jak działa AOP w Spring, jest to, że pisząc aspekt w Spring, używamy frameworka do budowania proxy dla twoich obiektów, z

JDKDynamicProxy

, jeśli Twój Bob implementuje interfejs lub przez CGLIB chyba że Twój Bob zaimplementuje jakiś interfejs. Pamiętaj, że musisz mieć cglib 2.2 w swojej ścieżce klas, jeśli używasz Springa przed 3.2. Od wiosny 3.2 jest to bezużyteczne, ponieważ cglib 2.2 był zawarty w jądrze.
Struktura utworzy serwer proxy, gdy zostanie utworzony Bob, który otacza twoje obiekty i dodaje kompleksowe funkcje, takie jak bezpieczeństwo, zarządzanie transakcjami, rejestrowanie i tak dalej.
Tworzenie proxy w ten sposób zostanie zastosowane, zaczynając od wyrażenia punktu przecięcia, które definiuje strukturę, aby zdecydować, które komponenty bean i metody zostaną utworzone jako proxy. Rada będzie bardziej odpowiedzialna niż twój kod. Pamiętaj, że w tym procesie punkt cięcia obejmuje tylko metody publiczne, które nie są uznane za ostateczne.
Teraz, podczas gdy w Spring AOP tkanie aspektów będzie wykonywane przez kontener po uruchomieniu kontenera, w AspectJ musisz to zrobić, a następnie skompilować kod poprzez modyfikację kodu bajtowego. Z tego powodu moim zdaniem podejście Springa jest prostsze i łatwiejsze w zarządzaniu niż AspectJ.
Z drugiej strony, w Spring AOP nie możesz wykorzystać pełnej mocy AOP, ponieważ implementacja odbywa się przez proxy, a nie przez modyfikacje kodu.
Podobnie jak w przypadku AspectJ, w SpringAOP możesz użyć tkania czasu rozruchu. Możesz skorzystać z tej funkcji wiosną zaimplementowanej przy użyciu agenta i niestandardowej konfiguracji,

@EnabledLoadWeaving

lub XML. Jako przykładu można użyć przestrzeni nazw. Jednak w Spring AOP nie możesz wyłapać wszystkich przypadków. Na przykład

new

nie jest obsługiwany w Spring AOP.
Jednak w Spring AOP możesz skorzystać z używania AspectJ z fabryczną metodą

Aspectof

w komponencie bean konfiguracji Spring.
Z tego powodu Spring AOP jest w zasadzie proxy utworzonym z kontenera, więc możesz używać AOP tylko dla wiosennych ziaren. Natomiast z AspectJ możesz używać aspektu we wszystkich swoich ziarnach. Kolejnym punktem porównania jest debugowanie i przewidywalność zachowania kodu. W przypadku Spring AOP zadanie jest generowane w całości z kompilatora Java, a aspekty są bardzo fajnym sposobem tworzenia proxy dla Twojego Spring Bob. W AspectJ, jeśli zmienisz kod, będziesz potrzebować więcej kompilacji i może być trudno zrozumieć, gdzie są splecione twoje aspekty. Nawet wyłączanie splotu na wiosnę jest łatwiejsze: za pomocą sprężyny usuwasz aspekt z konfiguracji, restartujesz i działa. W AspectJ musisz przekompilować kod!
W tkactwie AspectJ jest bardziej elastyczny niż Spring, ponieważ Spring nie obsługuje wszystkich opcji AspectJ. Ale moim zdaniem, jeśli chcesz zmienić proces tworzenia Boba, najlepszym rozwiązaniem jest zarządzanie niestandardowym logowaniem w fabryce, a nie tkanie aspektu czasu ładowania, który zmienia zachowanie twojego nowego operatora.
Mam nadzieję, że ta panorama AspectJ i Spring AOP pomoże ci zrozumieć różnicę między tymi dwoma miksturami

W tym

artykuł
https://www.baeldung.com/spring-aop-vs-aspectj
jest też dobre wyjaśnienie tego tematu.

Spring AOP i AspectJ mają różne cele.
Spring AOP ma na celu zapewnienie prostej implementacji AOP poprzez Spring
IoC do rozwiązywania najczęstszych problemów programistów.
Z drugiej strony AspectJ to oryginalna technologia AOP, która ma na celu
zapewniają kompletne rozwiązanie AOP.

W porównaniu do AOP, AspectJ nie musi ulepszać klasy docelowej w czasie kompilacji. Zamiast tego generuje klasę proxy dla klasy docelowej w czasie wykonywania, która albo implementuje ten sam interfejs, co klasa docelowa, albo jest podklasą klasy docelowej.
Zatem instancja klasy proxy może być używana jako instancja klasy docelowej. Ogólnie rzecz biorąc, AOP ulepszony w czasie kompilacji jest bardziej korzystny pod względem wydajności - ponieważ AOP ulepszony w czasie wykonywania wymaga dynamicznych ulepszeń przy każdym uruchomieniu.

Ważne jest, aby rozważyć, czy Twoje aspekty będą miały kluczowe znaczenie dla misji i gdzie zostanie wdrożony Twój kod. Spring AOP oznaczałby, że polegasz na czasie rozruchu splotu. To może nie działać, az mojego doświadczenia wynika, że ​​mogą istnieć zarejestrowane błędy, ale nie uniemożliwiają uruchomienia aplikacji bez kodu aspektu

[Dodałbym zastrzeżenie, że może być możliwe dostosowanie go w taki sposób, że tak nie jest; ale ja osobiście o tym nie wiem

]. Tkanie w czasie kompilacji pozwala na uniknięcie tego.
Ponadto, jeśli używasz AspectJ w połączeniu z wtyczką Aspectj-maven, możesz uruchomić testy jednostkowe dla swoich aspektów w środowisku CI i mieć pewność, że artefakty, które budujesz, są sprawdzane i tkane poprawnie. Chociaż możesz oczywiście pisać testy jednostkowe za pomocą dysku Spring, nadal nie masz gwarancji, że wdrożony kod będzie testowany w przypadku awarii LTW.
Inną kwestią jest to, czy hostujesz aplikację w środowisku, w którym możesz bezpośrednio kontrolować powodzenie lub niepowodzenie uruchomienia serwera/aplikacji, czy też aplikacja jest wdrażana w środowisku, nad którym nie masz nad nią kontroli [na przykład, gdzie jest hostowane przez klienta]. Ponownie, wskazywałoby to sposób tworzenia tkania w czasie kompilacji.
Pięć lat temu znacznie bardziej wspierałem SpringAOP z tego prostego powodu, że łatwiej było mi pracować i rzadziej żuć moje IDE. Jednak wraz ze wzrostem mocy obliczeniowej i dostępnej pamięci stało się to znacznie mniejszym problemem, a CTW z wtyczką Aspectj-maven stało się najlepszym wyborem w moim środowisku pracy z powodów, które opisałem powyżej.