Использование Spring AOP для ведения журнала - хорошая идея?

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

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

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

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

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


java logging spring spring-aop aop
person Omar Kooheji    schedule 15.01.2010    source источник

Ответы (3)


arrow_upward
17
arrow_downward

Прочтите эту запись в блоге о своей работе обеспокоенность.

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

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

person Bozho    schedule 15.01.2010

arrow_upward
41
arrow_downward

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

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

arrow_upward
3
arrow_downward

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

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

person lisak    schedule 20.07.2011
comment
Ссылка ведет на сайт блога, а не на настоящий блог по рассматриваемой теме. - person Sandeep Jindal; 17.10.2014
comment
@SandeepJindal Я отредактировал сообщение, чтобы обновить ссылку. - person vadipp; 04.02.2020