Пружина AOP является одной из основных частей каркаса пружины. На самом базовом этапе основа пружин основана на IoC и AOP. В официальном курсе весны есть слайд, на котором написано:
AOP является одной из наиболее важных частей фреймворка.
Ключевым моментом для понимания того, как работает AOP в Spring, является то, что когда вы пишете Aspect с помощью Spring, мы применяем платформу для построения прокси для ваших объектов, с JDKDynamicProxy, если ваш бин реализует интерфейс, или через CGLIB, если ваш Бин не реализует интерфейс. Помните, что вы должны иметь cglib 2.2 в вашем пути к классам, если вы используете Spring до версии 3.2. Начиная с Spring 3.2 это бесполезно, потому что в ядро был включен cglib 2.2.
Фреймворк при создании бина создаст прокси-сервер, который обернет ваши объекты и добавит сквозные задачи, такие как безопасность, управление транзакциями, ведение журнала и т. Д.
Создание прокси таким образом будет применяться, начиная с выражения pointcut, которое инструментирует платформу, чтобы решить, какие компоненты и методы будут созданы как прокси. Совет будет более ответственным, чем за ваш код. Помните, что в этом процессе pointcut захватывает только публичные методы, которые не объявлены как final.
Теперь, в то время как в Spring AOP ткачество аспектов будет выполняться контейнером при запуске контейнера, в AspectJ вы должны выполнить это после посткомпиляции кода с помощью модификации байт-кода. По этой причине, на мой взгляд, подход Spring проще и более управляем, чем AspectJ.
С другой стороны, в Spring AOP вы не можете использовать все возможности AOP, поскольку реализация осуществляется через прокси-серверы, а не с помощью модификации вашего кода.
Как и в AspectJ, вы можете использовать время загрузки в SpringAOP. Вы можете извлечь выгоду из этой функции весной, реализованной с помощью агента и специальных конфигураций, @EnabledLoadWeaving или в XML. Вы можете использовать пространство имен в качестве примера. Однако в Spring AOP вы не можете перехватить все случаи. Например, команда new не поддерживается в Spring AOP.
Однако в Spring AOP вы можете извлечь выгоду из использования AspectJ благодаря использованию фабричного метода aspectof в компоненте конфигурации Spring.
По той причине, что Spring AOP - это в основном прокси, созданный из контейнера, поэтому вы можете использовать AOP только для Spring Bean. В то время как с AspectJ вы можете использовать аспект во всех ваших бобах. Еще одна точка сравнения - отладка и предсказуемость поведения кода. В Spring AOP все задание выполняется с помощью компилятора Java, а аспекты являются очень хорошим способом создания прокси для вашего компонента Spring. В AspectJ, если вы модифицируете код, вам нужно больше компилировать, и понять, где сплетены ваши аспекты, может быть сложно. Даже выключить ткачество весной проще: с помощью пружины вы удаляете аспект из вашей конфигурации, перезапускаете, и это работает. В AspectJ вы должны перекомпилировать код!
В ткачестве во время загрузки AspectJ более гибок, чем Spring, потому что Spring не поддерживает все параметры AspectJ. Но, на мой взгляд, если вы хотите изменить процесс создания bean-компонента, лучшим способом будет управление пользовательским входом в систему на фабрике, а не ткачество во время загрузки аспекта, который меняет поведение вашего нового оператора.
Я надеюсь, что этот обзор AspectJ и Spring AOP поможет вам понять разницу двух зелий