Является ли использование Spring AOP для регистрации хорошей идеей?

Question

В данный момент я читаю о Spring, и один из примеров использования AOP - регистрация начала и конца вызовов методов.

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

Является ли использование Spring AOP хорошей идеей для ведения журнала такого типа? Насколько я понимаю, Spring использует Dynamic AOP, было бы лучше использовать Static AOP (например, AspectJ) для этого типа AOP.

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

Я лаю не на том дереве?

Answer 1

Я использовал Spring AOP для реализации ведения журнала, поэтому я делюсь своими наблюдениями:

• Влияние на производительность недостаточно, оно меньше, чем влияние самой регистрации
• Имея аспекты, настроенные в конфигурации Spring, вы можете полностью отключить код регистрации при необходимости
• Отладка становится более проблематичной, так как трассировка стека становится более длинной
• Такое решение существенно влияет на дизайн. Вы не только получаете кучу интерфейсов и классов аспектов, но и ваши производственные классы должны быть очень «тонкими». Не забывайте, что вы не можете перехватывать вызовы закрытых методов. Собственные вызовы (даже для общедоступных методов) также не могут быть перехвачены (так как вы работаете с голым this дескриптором вместо дескриптора, обернутого AOP) и, следовательно, не могут быть зарегистрированы. Таким образом, вся регистрация может происходить только на границах интерфейса. (Это касается использования аспектов на основе Proxy, есть опция создания подклассов во время выполнения с помощью cglib, но я ее не использовал)
• Написание меток может быть очень сложным. IntelliJ Idea помогает в значительной степени определить, какие методы следует рекомендовать pointcut.
• В общем, мне понравился этот подход, и я думаю, что его стоит использовать, но он оказался намного сложнее, чем я ожидал

Answer 2

Прочитайте этот блог о ваших проблемах производительности.

Способ думать об АОП - поставить поставленные функциональные преимущества на первое место. Если автоматическое ведение журнала является вашим требованием и AOP подходит для этого - сделайте это.

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

Answer 3

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

Имхо, оно того не стоит, если только вы не делаете что-то более хитрое, чем ведение журнала, например, управление ошибками с постоянством. Если у вас есть хорошая иерархия исключений (домен, система) и правильно установлены границы ведения журнала, вы не будете сильно уменьшать код ведения журнала.