Spring AOP vs AspectJ

Question

Ho l'impressione che la primavera AOP è meglio utilizzato per compiti specifici di applicazioni come la sicurezza, la registrazione, le transazioni, ecc in quanto utilizza le annotazioni java5 personalizzata come un quadro. Tuttavia, AspectJ sembra essere più amichevole nei modelli di progettazione.

Chiunque può evidenziare i vari pro e contro dell'utilizzo di Spring AOP vs AspectJ in un'applicazione primavera?

Answer 1

Primavera-AOP Pro

• E 'più semplice da usare rispetto AspectJ, dal momento che non c'è bisogno di usare LTW (load-time weaving) o il compilatore AspectJ.

• utilizza il modello di delega e il decoratore modello

Primavera-AOP Contro

• Questa è basata su proxy AOP, in modo sostanzialmente è possibile utilizzare solo joinpoint metodo-di esecuzione.
• Aspetti non vengono applicate quando si chiama un altro metodo all'interno della stessa classe.
• Ci può essere un piccolo sovraccarico di runtime.
• Primavera-AOP non può aggiungere un aspetto a tutto ciò che non è creato dalla fabbrica Primavera

AspectJ Pro

• Questo supporta tutti joinpoint. Questo significa che puoi fare qualsiasi cosa.
• c'è meno spese generali di esecuzione di quella di primavera AOP.

AspectJ Contro

• Attenzione. Verifica se i tuoi aspetti sono intrecciati solo a ciò che desideri essere intessuto.
• è necessario processo di compilazione in più con AspectJ compilatore o devono impostazione LTW (load-time di tessitura)

Answer 2

The spring user manual darà un sacco di informazioni, direttamente dalla bocca del cavallo.

Il capitolo 6.4 - Choosing which AOP declaration style to use è morto per voi dato che discute i pro ei contro di entrambi.

Il paragrafo 6.1.2 - Spring AOP Capabilites and goals & i capitoli 6.2 - @Aspect support e 6.8 - Using AspectJ with Spring applications dovrebbero essere particolarmente interessanti.

Answer 3

A parte ciò che altri hanno detto - solo per riformulare, there are two major differences:

1. Uno è legato al tipo di tessitura.
2. Un altro per la definizione del joinpoint.

Primavera-AOP: Runtime tessitura attraverso proxy che utilizza il concetto di dynamic proxy if interface exists or cglib library if direct implementation provided.

AspectJ: tempo di compilazione tessitura attraverso AspectJ Java Tools(ajc compiler) se sorgente disponibile o inviati compilazione tessitura (utilizzando i file compilati). Inoltre, è possibile abilitare il tempo di caricamento con Spring, ha bisogno del file di definizione aspectj e offre flessibilità.

tempo di compilazione di tessitura in grado di offrire vantaggi di prestazioni (in alcuni casi) e anche la joinpoint definition in Spring-aop is restricted to method definition only which is not the case for AspectJ.

Answer 4

Una nota ulteriore: Se le prestazioni sotto carico elevato è importante, ti consigliamo AspectJ che è più veloce di 9-35x Spring AOP. 10ns vs 355ns potrebbero non sembrare molto, ma ho visto persone usare LOTS of Aspects. 10K di aspetti. In questi casi, la tua richiesta potrebbe interessare migliaia di aspetti. In quel caso stai aggiungendo ms a quella richiesta.

Vedere benchmarks.

Answer 5

Spring AOP è una delle parti essenziali della struttura della molla. Nella fase di base, il framework primaverile è basato su IoC e AOP. Nel corso ufficiale di primavera è presente una diapositiva in cui è indicato:

L'AOP è una delle parti più importanti del framework.

Il punto chiave per capire il funzionamento AOP in primavera è che quando si scrive un aspetto con la Primavera ci strumento quadro con la costruzione di un proxy per gli oggetti, con un JDKDynamicProxy se il bean implementa un'interfaccia o tramite CGLIB se il tuo bean non implementa alcuna interfaccia. Ricorda che devi avere cglib 2.2 nel percorso della tua classe se usi Spring prima della versione 3.2. A partire dalla primavera 3.2 è inutile perché cglib 2.2 è stato incluso nel core.

Il framework alla creazione del bean creerà un proxy che avvolge gli oggetti e aggiunge preoccupazioni trasversali quali la sicurezza, la gestione delle transazioni, la registrazione e così via.

La creazione proxy in questo modo verrà applicata a partire da un'espressione pointcut che funge da framework per decidere quali bean e metodi verranno creati come proxy. Il consiglio sarà più la responsabilità che per il tuo codice. Ricorda che in questo processo il pointcut acquisisce solo metodi pubblici che non sono dichiarati definitivi.

Ora, mentre in Primavera AOP la trama degli Aspetti verrà eseguita dal contenitore all'avvio del contenitore, in AspectJ è necessario eseguire questa operazione con una compilazione del codice tramite la modifica del bytecode. Per questo motivo, a mio parere, l'approccio Spring è più semplice e più gestibile di AspectJ.

D'altra parte, con Spring AOP non è possibile utilizzare tutta la potenza di AOP perché l'implementazione avviene tramite proxy e non con la modifica del codice.

Come in AspectJ, è possibile utilizzare la tessitura a tempo di caricamento in SpringAOP. È possibile beneficiare di questa funzionalità in primavera è implementato con un agente e configurazioni speciali, @EnabledLoadWeaving o in XML. Puoi usare lo spazio dei nomi come esempio. Tuttavia in Spring AOP non è possibile intercettare tutti i casi. Ad esempio, il comando new non è supportato in Spring AOP.

Tuttavia in Spring AOP è possibile beneficiare dell'utilizzo di AspectJ mediante l'uso del metodo di produzione aspectof nel bean di configurazione Spring.

Per il motivo che Spring AOP è fondamentalmente un proxy creato dal contenitore, quindi è possibile utilizzare AOP solo per i bean spring. Mentre con AspectJ puoi usare l'aspetto in tutti i tuoi fagioli. Un altro punto di confronto è il debug e la prevedibilità del comportamento del codice. Con Spring AOP, il lavoro è preformato tutto dal compilatore Java e gli aspetti sono un modo molto interessante per creare proxy per il bean Spring. In AspectJ se modifichi il codice, hai bisogno di più compilazione e di capire dove i tuoi aspetti sono intrecciati potrebbe essere difficile. Anche chiudere la tessitura in primavera è più semplice: con la molla rimuovi l'aspetto dalla tua configurazione, riavvia e funziona. In AspectJ devi ricompilare il codice!

Nella tessitura a tempo di caricamento, AspectJ è più flessibile di Spring perché Spring non supporta tutte le opzioni di AspectJ. Ma a mio parere Se si desidera modificare il processo di creazione di un bean, un modo migliore è gestire l'accesso personalizzato in una fabbrica e non con la tessitura a carico del tempo di un aspetto che modifica il comportamento del nuovo operatore.

Spero che questa panoramica di AspectJ e Spring AOP ti aiuta a capire la differenza delle due pozioni

Answer 6

E 'importante considerare se i vostri aspetti saranno mission critical e in cui viene distribuito il codice. Spring AOP significa che ti affidi alla tessitura a tempo di caricamento. Questo può non riuscire a tessere e nella mia esperienza ha significato che possono esistere errori registrati ma non impediscono l'esecuzione dell'applicazione senza codice aspetto [Vorrei aggiungere l'avvertenza che potrebbe essere possibile configurarlo in modo tale che questo non sia il caso; ma non ne sono personalmente a conoscenza]. La tessitura in fase di compilazione evita questo.

Inoltre, se si utilizza AspectJ in combinazione con il plugin aspectj-maven, è possibile eseguire test unitari sui propri aspetti in un ambiente CI e avere la certezza che gli artefatti costruiti siano stati testati e tessuti correttamente. Mentre è certamente possibile scrivere i test delle unità Spring, non si ha ancora alcuna garanzia che il codice distribuito sarà quello che è stato testato se l'LTW fallisce.

Un'altra considerazione è se si sta ospitando l'applicazione in un ambiente in cui si è in grado di monitorare direttamente il successo o il fallimento di un avvio di server/applicazione o se la propria applicazione viene distribuita in un ambiente in cui non è sotto la vostra supervisione [per esempio dove è ospitato da un cliente]. Di nuovo, questo indicherà il modo di compilare la tessitura del tempo.

Cinque anni fa, ero molto più a favore di Spring configurato AOP per la semplice ragione che era più facile lavorare con e meno probabilità di masticare il mio IDE. Tuttavia, poiché la potenza di calcolo e la memoria disponibile sono aumentate, questo è diventato molto meno un problema e CTW con il plugin aspectj-maven è diventato una scelta migliore nel mio ambiente di lavoro in base alle ragioni che ho descritto sopra.