A tavaszi AOP és az AspectJ összehasonlítása

1. Bemutatkozás

Ma több AOP könyvtár áll rendelkezésre, és ezeknek számos kérdésre választ kell tudniuk:

  • Kompatibilis a meglévő vagy új alkalmazásommal?
  • Hol tudom megvalósítani az AOP-t?
  • Milyen gyorsan integrálódik az alkalmazásommal?
  • Mi a teljesítmény rezsije?

Ebben a cikkben megvizsgáljuk ezekre a kérdésekre adott válaszokat, és bemutatjuk a Spring AOP-t és az AspectJ-t - a Java két legnépszerűbb AOP-keretrendszerét.

2. AOP koncepciók

Mielőtt nekilátnánk, végezzünk egy gyors, magas szintű áttekintést a kifejezésekről és az alapvető fogalmakról:

  • Aspect - szabványos kód / szolgáltatás, amely az alkalmazás több helyén szétszórva jellemzően eltér a tényleges üzleti logikától (például Tranzakció-kezelés). Minden szempont egy adott átfogó funkcionalitásra összpontosít
  • Joinpoint - ez egy bizonyos pont olyan programok végrehajtása során, mint a metódus végrehajtása, a konstruktor hívása vagy a terepi hozzárendelés
  • Tanács - a szempont által egy adott csatlakozási pontban végrehajtott művelet
  • Pointcut - egy szabályos kifejezés, amely illeszkedik egy csatlakozási ponthoz. Valahányszor bármely csatlakozási pont megegyezik egy pontvágással, végrehajtják az adott pontvágáshoz társított meghatározott tanácsokat
  • Szövés - a szempontok és a megcélzott objektumok összekapcsolásának folyamata egy tanácsos objektum létrehozása érdekében

3. Tavaszi AOP és AspectJ

Most tárgyaljuk meg a Spring AOP-t és az AspectJ-t számos tengelyen - például képességek, célok, szövés, belső szerkezet, csatlakozási pontok és egyszerűség.

3.1. Képességek és célok

Egyszerűen fogalmazva, a Spring AOP és az AspectJ célja más.

A tavaszi AOP célja egy egyszerű AOP megvalósítás biztosítása a tavaszi IoC-ban, hogy megoldja a programozók leggyakoribb problémáit. Nem célja a teljes AOP megoldás - csak azokra a babokra alkalmazható, amelyeket tavaszi tartály kezel.

Másrészről, Az AspectJ az eredeti AOP technológia, amelynek célja a teljes AOP megoldás biztosítása. Robusztusabb, de lényegesen bonyolultabb, mint a tavaszi AOP. Érdemes megjegyezni azt is, hogy az AspectJ minden tartományi objektumra alkalmazható.

3.2. Szövés

Az AspectJ és a Spring AOP is különböző típusú szövéseket alkalmaz, amelyek befolyásolják viselkedésüket a teljesítmény és a könnyű használat szempontjából.

Az AspectJ háromféle szövést alkalmaz:

  1. Összeállítású szövés: Az AspectJ fordító inputként veszi mind a szempontunk forráskódját, mind az alkalmazásunkat, és egy szőtt osztályfájlt állít elő kimenetként
  2. Összeállítás utáni szövés: Ezt bináris szövésnek is nevezik. A meglévő osztályfájlok és a JAR fájlok szövésére használják a szempontjainkkal
  3. Terheléses szövés: Pontosan olyan, mint a korábbi bináris szövés, azzal a különbséggel, hogy a szövést elhalasztják, amíg egy osztálybetöltő be nem tölti az osztályfájlokat a JVM-be

Magával az AspectJ-vel kapcsolatos részletesebb információkért olvassa el ezt a cikket.

Mivel az AspectJ fordítási és osztályozási idő szövést használ, A tavaszi AOP futásidejű szövést alkalmaz.

Futásidejű szövés esetén a szempontok az alkalmazás végrehajtása során szövődnek a megcélzott objektum proxyk segítségével - JDK dinamikus vagy CGLIB proxy használatával (amelyeket a következő pont tárgyal).

3.3. Belső felépítés és alkalmazás

A tavaszi AOP egy proxy alapú AOP keretrendszer. Ez azt jelenti, hogy a célobjektumok aspektusainak megvalósításához proxykat hoz létre az objektumról. Ezt kétféle módon lehet elérni:

  1. JDK dinamikus proxy - a Spring AOP előnyben részesített módja. Amikor a megcélzott objektum akár egyetlen interfészt is megvalósít, akkor a JDK dinamikus proxyt kell használni
  2. CGLIB proxy - ha a célobjektum nem valósít meg interfészt, akkor CGLIB proxy használható

A tavaszi AOP proxy mechanizmusokról többet megtudhatunk a hivatalos dokumentumokból.

Az AspectJ viszont nem tesz semmit futás közben, mivel az osztályokat közvetlenül szempontokkal állítják össze.

Tehát a tavaszi AOP-tól eltérően nem igényel semmilyen tervezési mintát. A kód szempontjainak szövése érdekében bevezeti az AspectJ fordító (ajc) néven ismert fordítóját, amelyen keresztül összeállítjuk programunkat, majd egy kis (<100K) futásidejű könyvtár szállításával futtatjuk.

3.4. Csatlakozási pontok

A 3.3 szakaszban megmutattuk, hogy a Spring AOP proxy mintákon alapul. Emiatt alosztályba kell sorolnia a megcélzott Java osztályt, és ennek megfelelően átfogó szempontokat kell alkalmaznia.

De korlátozással jár. Nem alkalmazhatunk átfogó aggályokat (vagy szempontokat) a „végleges” osztályok között, mert ezeket nem lehet felülbírálni, és ez futásidejű kivételt eredményezne.

Ugyanez vonatkozik a statikus és a végső módszerekre is. A tavaszi szempontok nem alkalmazhatók rájuk, mert nem írhatók felül. Ezért a tavaszi AOP ezen korlátozások miatt csak a metódus végrehajtásának egyesítési pontjait támogatja.

Azonban, Az AspectJ futásidő előtt közvetlenül a tényleges kódba szövi átfogó aggályait. A tavaszi AOP-tól eltérően nem szükséges a célzott objektum alosztálya, így sok más csatlakozási pontot is támogat. Az alábbiakban összefoglaljuk a támogatott csatlakozási pontokat:

JoinpointTavaszi AOP támogatottAspectJ támogatott
Method CallNemIgen
Módszer végrehajtásaIgenIgen
Konstruktor hívásNemIgen
Konstruktor végrehajtásaNemIgen
Statikus inicializáló végrehajtásNemIgen
Objektum inicializálásaNemIgen
Terepi hivatkozásNemIgen
Terepi hozzárendelésNemIgen
Kezelő végrehajtásaNemIgen
Tanácsadás végrehajtásaNemIgen

Érdemes megjegyezni azt is, hogy a tavaszi AOP-ban a szempontokat nem alkalmazzák az ugyanazon osztályon belül meghívott módszerre.

Ez nyilvánvalóan azért van, mert amikor metódust hívunk meg ugyanazon az osztályon belül, akkor nem a tavaszi AOP által biztosított proxy módszerét hívjuk meg. Ha szükségünk van erre a funkcióra, akkor külön módszert kell meghatároznunk a különböző babokban, vagy az AspectJ-t kell használnunk.

3.5. Egyszerűség

A tavaszi AOP nyilvánvalóan egyszerűbb, mert nem vezet be extra fordítót vagy szövőt az építési folyamatunk közé. Futásidejű szövést használ, ezért zökkenőmentesen integrálódik a szokásos építési folyamatunkba. Bár egyszerűnek tűnik, csak a Spring által kezelt babokkal működik.

Az AspectJ használatához azonban be kell vezetnünk az AspectJ fordítót (ajc), és újra össze kell csomagolnunk az összes könyvtárunkat (hacsak nem váltunk át fordítás utáni vagy betöltési idejű szövésre).

Ez természetesen bonyolultabb, mint az előbbi - mert bevezeti az AspectJ Java Tools alkalmazást (amely tartalmaz egy fordítót (ajc), egy hibakeresőt (ajdb), egy dokumentációs generátort (ajdoc), egy programstruktúra böngészőt (ajbrowser)), amelyet integrálódnunk kell az IDE-vel vagy a build eszközzel.

3.6. Teljesítmény

Ami a teljesítményt illeti, a fordítási idejű szövés sokkal gyorsabb, mint a futásidejű szövés. A tavaszi AOP egy proxy alapú keretrendszer, így az alkalmazás indításakor létrejönnek a proxyk. Szintén van még néhány módszerhívás szempontonként, ami negatívan befolyásolja a teljesítményt.

Másrészről az AspectJ az alkalmazás végrehajtása előtt szövi be a szempontokat a fő kódba, és így a Spring AOP-tól eltérően nincs további futásidejű költség.

Ezen okokból a referenciaértékek azt sugallják, hogy az AspectJ csaknem 8-35-szer gyorsabb, mint a tavaszi AOP.

4. Összefoglalás

Ez a gyors táblázat összefoglalja a Spring AOP és az AspectJ legfontosabb különbségeit:

Tavaszi AOPAspectJ
Tiszta Java-ban implementálvaA Java programozási nyelv kiterjesztéseivel valósult meg
Nincs szükség külön fordítási folyamatraSzüksége van AspectJ fordítóra (ajc), hacsak az LTW nincs beállítva
Csak futásidejű szövés érhető elFutásidejű szövés nem érhető el. Támogatja a fordítási idejű, utólagos és a betöltési idejű szövést
Kevésbé hatékony - csak a módszer szintű szövést támogatjaErőteljesebb - képes szőni mezőket, módszereket, konstruktorokat, statikus inicializálókat, végső osztályt / módszereket stb.
Csak a tavaszi konténer által kezelt babokon lehet megvalósítaniMinden tartományi objektumon megvalósítható
Csak a metódus végrehajtási pontokat támogatjaTámogatja az összes pontot
Megcélzott objektumokhoz proxykat hoznak létre, és ezekre a proxykra aspektusokat alkalmaznakAz aspektusokat közvetlenül az alkalmazás futtatása előtt futtatják a kódba (futásidő előtt)
Sokkal lassabban, mint az AspectJJobb teljesítmény
Könnyen megtanulható és alkalmazhatóÖsszehasonlítva bonyolultabb, mint a tavaszi AOP

5. A megfelelő keret kiválasztása

Ha elemezzük az ebben a szakaszban felhozott összes érvet, akkor kezdjük megérteni, hogy egyáltalán nem az, hogy az egyik keretrendszer jobb a másiknál.

Egyszerűen fogalmazva: a választás nagyban függ az igényeinktől:

  • Keret: Ha az alkalmazás nem a Spring keretrendszert használja, akkor nincs más lehetőségünk, mint elvetni a Spring AOP használatának ötletét, mert nem tud kezelni semmit, ami a tavaszi konténer hatókörén kívül esik. Ha azonban alkalmazásunkat teljes egészében a Spring keretrendszerrel készítjük el, akkor a Spring AOP-t használhatjuk, mivel a tanulás és alkalmazás egyszerű
  • Rugalmasság: Tekintettel a korlátozott csatlakozási pont támogatásra, a Spring AOP nem teljes AOP megoldás, de megoldja a leggyakoribb problémákat, amelyekkel a programozók szembesülnek. Bár ha mélyebbre akarunk ásni és maximálisan kihasználni akarjuk az AOP-t, és a rendelkezésre álló csatlakozási pontok széles skáláját szeretnénk támogatni, akkor az AspectJ a választás
  • Teljesítmény: Ha korlátozott szempontokat használunk, akkor triviális teljesítménybeli különbségek vannak. De vannak olyan esetek, amikor egy alkalmazásnak több mint tízezer szempontja van. Ilyen esetekben nem szeretnénk futásidejű szövést használni, ezért jobb lenne az AspectJ mellett dönteni. Az AspectJ 8-35-szer gyorsabb, mint a tavaszi AOP
  • A legjobb mindkettőben: Mindkét keret teljes mértékben kompatibilis egymással. Bármikor kihasználhatjuk a tavaszi AOP előnyeit, és továbbra is használhatjuk az AspectJ-t az olyan csatlakozási pontok támogatásához, amelyeket az előbbiek nem támogatnak

6. Következtetés

Ebben a cikkben a Spring AOP-t és az AspectJ-t is elemeztük, több kulcsfontosságú területen.

Összehasonlítottuk az AOP két megközelítését mind a rugalmasság, mind pedig az, hogy mennyire könnyen illeszkednek majd alkalmazásunkhoz.


$config[zx-auto] not found$config[zx-overlay] not found