Какое наиболее распространенное использование для АОП в весеннем проекте

Question

После просмотра шаблона AOP, я поражен тем, как и для чего его использовать в моем весеннем проекте.

Я бы хотел использовать его в качестве системы журнала аудита всей финансовой бизнес-логики. Просто кажется, что это легко интегрировать. Но я бы хотел услышать ваше мнение об этом.

Вопрос в том, какие еще варианты следует учитывать, которые являются общими для этого шаблона? Я не возражаю против рефакторинга моей текущей логики для использования с AOP, если есть преимущества для нее.

Answer 1

Наиболее распространенное использование - это когда ваше приложение имеет сквозные проблемы, то есть кусок логики или кода, который будет написан в нескольких классах / слоях.

И это может варьироваться в зависимости от ваших потребностей. Некоторые очень распространенные примеры этого могут быть:

1. Управление транзакциями
2. Регистрация
3. Обработка исключений (особенно, если вы хотите иметь подробные трассировки или иметь какой-то план восстановления после исключений)
4. Аспекты безопасности
5. Инструменты

Надеюсь, это поможет.

Answer 2

Помимо регистрации / аудита и декларативной обработки транзакций, как упомянуто Axel, я бы сказал, что еще одно использование AOP - это перехватчик запросов.Например, допустим, вам необходимо перехватывать все поступающие от сервера запросы, чтобы вы могли что-то с ним сделать (возможно, отслеживать, какое приложение отправляет какой запрос в какое другое приложение или в какую базу данных и т. Д.).

Answer 3

Наиболее распространенным использованием, вероятно, является декларативная обработка транзакций с использованием @Transactional.

Answer 4

Вы можете использовать AOP в целях безопасности, например, разрешить / запретить доступ к методу.Другое использование aop - проверка производительности вашего приложения.

Answer 5

Может использоваться для предоставления пользовательских метрик (Инструментарий службы) для оповещения и мониторинга службы с использованием клиентских библиотек, таких как dropwizard, prometheus.

Это помогло нам,

1. Храните этот код инструментария (не бизнес-логики) вне реальной бизнес-логики

2. Храните эти сквозные проблемы в одном месте.

3. Декларативно применять их везде, где требуется.

Например, чтобы выставить

1. Всего байтов, возвращенных REST AIP - (Можетдолжно быть сделано после консультации)
2. Общее время, затрачиваемое REST API, т.е. время на входе и выходе сервера (может быть сделано с использованием рекомендаций).

Answer 6

Поскольку ответ немного отличается от того, что сказал @Axel, использование его для автоматического перехвата всех ваших вызовов доступа к данным и надлежащего применения транзакций является феноменальным.У меня есть мой, настроенный для реализации всех вызовов к моему пакету dao, которые не начинаются с «get» в транзакции, и затем все, что выполняется в методе, начинающемся с «get», обрабатывается только для чтения.Это фантастика, потому что, кроме начальной настройки, мне не нужно об этом беспокоиться, просто следуйте соглашению об именах.

Answer 7

Использование AOP для ведения журнала аудита является вполне допустимым использованием AOP. Вы можете отключить его для тестирования и изменять по мере изменения требований в процессе производства.

Единственным недостатком в этом случае является то, что вы планировали вести журнал аудита с помощью SQL. Это может быть более эффективным для реализации такого рода аудита как триггеров непосредственно в БД.