Весняний AOP проти AspectJ

Я маю враження, що Spring AOP найкраще використовувати для конкретних завдань, таких як безпека, ведення журналів, транзакції тощо, оскільки він використовує власні анотації Java5 як основу. Однак, схоже, AspectJ виглядає більш дружньою схемою дизайну.

Чи може хтось виділити різні плюси і мінуси використання Spring AOP проти AspectJ у додатку Spring?

Плюси весни-AOP

• Він простіший у використанні, ніж AspectJ, оскільки вам не доведеться використовувати LTW ( ткацький час завантаження ) або компілятор AspectJ.

• Він використовує шаблон проксі і візерунок декоратора

Весна-АОП Мінуси

• Це AOP на основі проксі, тому в основному ви можете використовувати лише з'єднувальні точки для виконання методу.
• Аспекти не застосовуються під час виклику іншого методу в межах одного класу.
• Може бути невеликий час виконання.
• Spring-AOP не може додати аспект до нічого, що не створено заводом Spring

Плюси аспектуJ

• Це підтримує всі точки з'єднання. Це означає, що ви можете зробити все, що завгодно.
• Час виконання триває менше, ніж у Spring AOP.

Мінуси AspectJ

• Будь обережний. Перевірте, чи ваші аспекти переплетені лише на те, що ви хотіли плести.
• Вам потрібен додатковий процес збирання з AspectJ Compiler або потрібно встановити LTW (плетіння часу навантаження)

Крім того, що інші заявили - просто перефразовуючи there are two major differences:

1. Один пов'язаний з типом плетіння.
2. Ще одне до визначення точки з'єднання.

Весна-AOP: Тривалість виконання через проксі, використовуючи концепціюdynamic proxy if interface exists or cglib library if direct implementation provided.

AspectJ: компілюйте час переплетення за AspectJ Java Tools(ajc compiler)наявності наявного джерела чи після компіляційного плетіння (використовуючи компільовані файли). Також можна включити плетіння часу за допомогою Spring - він потребує aspectjфайлу визначення та пропонує гнучкість.

Складання часу на компіляції може запропонувати переваги продуктивності (в деяких випадках), а також joinpoint definition in Spring-aop is restricted to method definition only which is not the case for AspectJ.

Додаткова примітка: Якщо продуктивність при високому навантаженні важлива, вам потрібен AspectJ, який на 9-35 разів швидше, ніж Spring AOP . 10ns проти 355ns може здатися не так вже й багато, але я бачив людей, які використовують багато аспектів. 10K вартості аспектів. У цих випадках ваш запит може торкнутися тисячі аспектів. У цьому випадку ви додаєте повідомлення до цього запиту.

Дивіться орієнтири .

Весняний посібник користувача дасть багато інформації прямо з вуст коня.

Розділ 6.4 - Вибір стилю оголошення AOP для вас мертвий, оскільки він обговорює плюси та мінуси обох.

Пункт 6.1.2 - Весняні канали AOP та цілі та глави 6.2 - Підтримка @Aspect та 6.8 - Використання AspectJ у програмах Spring мають бути особливо цікавими.

Весняний АОП - одна з найважливіших частин весняних рамок. На самому базовому етапі весняні рамки базуються на IoC та AOP. В офіційному курсі Весна є слайд, на якому написано:

AOP - одна з найважливіших частин основи.

Ключовим моментом для розуміння того, як працює AOP Spring, є те, що коли ви пишете Аспект з Spring, ми встановлюємо основу зі створення проксі-сервера для ваших об'єктів, JDKDynamicProxyякщо a- bean реалізує інтерфейс або через CGLIB, якщо ваш bean не реалізує жодного інтерфейс. Пам'ятайте, що ви повинні мати cglib 2.2 у своєму класі-шляху, якщо ви використовуєте Spring до версії 3.2. Починаючи з весни 3.2, це марно, оскільки в основу було включено кліб 2.2.

Рамка при створенні bean створить проксі-сервер, який обгортає ваші об'єкти і додає наскрізних питань, пов'язаних з відповідальністю, такими як безпека, управління транзакціями, ведення журналів тощо.

Створення проксі-сервера таким чином буде застосовано, починаючи з точкового виразу, який інструментує рамки для вирішення того, які боби та методи будуть створені як проксі. Порада буде більшою відповідальністю, ніж за ваш код. Пам’ятайте, що в цьому процесі пунктир фіксує лише публічні методи, які не оголошуються як остаточні.

Тепер, поки у Spring AOP плетіння аспектів буде виконуватися контейнером при запуску контейнера, в AspectJ вам доведеться виконати це з подальшим складанням вашого коду шляхом зміни байт-коду. З цієї причини, на мій погляд, підхід Spring є більш простим і керованим, ніж AspectJ.

З іншого боку, за допомогою Spring AOP ви не можете використовувати всю потужність AOP, оскільки реалізація здійснюється через проксі, а не за допомогою зміни вашого коду.

Як і в AspectJ, у SpringAOP можна використовувати плетіння часу. Ви можете скористатися цією функцією навесні, реалізованої за допомогою агента та спеціальних конфігурацій, @EnabledLoadWeavingабо в XML. Ви можете використовувати простір імен як приклад. Однак у Spring AOP ви не можете перехопити всі справи. Наприклад, newкоманда не підтримується у Spring AOP.

Однак у Spring AOP ви можете скористатися використанням AspectJ завдяки використанню aspectofфабричного методу в пружинній конфігурації.

З тієї причини, що Spring AOP - це в основному проксі, створений з контейнера, тому ви можете використовувати AOP лише для весняних бобів. У той час як з AspectJ ви можете використовувати цей аспект у всіх своїх зернах. Іншим моментом порівняння є налагодження та передбачуваність поведінки коду. Завдяки Spring AOP ця робота попередньо формується з компілятора Java, і аспекти є дуже класним способом створення проксі для вашого Spring Bean. Якщо ви модифікуєте код AspectJ, вам потрібно більше компілювати, і зрозуміти, де ваші аспекти сплетені, може бути важко. Навіть вимкнення плетіння навесні простіше: весною ви видалите аспект зі своєї конфігурації, перезапустіть і воно працює. В AspectJ ви повинні перекомпілювати код!

У плетінні часу навантаження, AspectJ є більш гнучким, ніж весна, тому що Spring не підтримує всі параметри AspectJ. Але, на мою думку, якщо ви хочете змінити процес створення квасолі, кращим способом є керування користувальницьким входом на фабрику, а не за допомогою плетіння часу, який змінює поведінку вашого нового оператора.

Я сподіваюся, що ця панорама на AspectJ та Spring AOP допоможе вам зрозуміти різницю двох зілля

Важливо врахувати, чи будуть ваші аспекти критично важливими для місії та де розгортається ваш код. Весняний АОП означатиме, що ви покладаєтесь на плетіння часу. Це не може сплести, і, на мій досвід, це означає, що введені помилки можуть існувати, але це не заважатиме програмі працювати без коду аспекту [я б додав застереження, що можливо можливо налаштувати його таким чином, що це не справа; але я особисто цього не знаю ]. Плетіння в компільований час уникає цього.

Крім того, якщо ви використовуєте AspectJ спільно з плагіном аспект-maven, ви зможете запустити одиничні тести на ваші аспекти в середовищі CI і впевнені, що вбудовані артефакти перевірені та правильно виткані. Незважаючи на те, що ви, звичайно, можете писати тестові модулі на весняних блоках, ви все ще не маєте гарантії, що розгорнутий код буде тим, який був перевірений, якщо LTW не вдасться.

Інша думка полягає в тому, чи розміщуєте ви програму в середовищі, де ви можете безпосередньо відстежувати успіх чи збій запуску сервера / програми чи розгортаєте вашу програму в середовищі, де це не знаходиться під вашим наглядом [наприклад, де це розміщується клієнт]. Знову ж, це вказувало б на спосіб складання часу.

П'ять років тому я був набагато більше прихильний до того, що Spring налаштував AOP з тієї простої причини, що було легше працювати і менше шансів пережовувати мій IDE. Однак у міру збільшення обчислювальної потужності та доступної пам’яті це стало набагато меншою проблемою, і CTW з плагінjjj-maven-плагіном став кращим вибором у моєму робочому середовищі, виходячи з причин, зазначених вище.

У цій статті також є гарне пояснення щодо теми.

Весна AOP і AspectJ мають різні цілі.

Spring AOP має на меті забезпечити просту реалізацію AOP у Spring IoC для вирішення найпоширеніших проблем, з якими стикаються програмісти.

З іншого боку, AspectJ - це оригінальна технологія AOP, яка має на меті забезпечити повноцінне рішення AOP.

Порівняно з AOP, AspectJ не потребує підвищення цільового класу під час компіляції. Натомість він створює проксі-клас для цільового класу під час виконання, який або реалізує той же інтерфейс, що і цільовий клас, або є підкласом цільового класу.

Підсумовуючи це, екземпляр проксі-класу може використовуватися як екземпляр цільового класу. Взагалі, розширена рамка AOP, складена під час компіляції, є більш вигідною за своєю ефективністю - тому що рамки AOP, покращені під час виконання, вимагають динамічних удосконалень кожного разу, коли вона працює.