И снова здравствуйте! В прошлый раз при обсуждении АОП, мы с вами говорили о решении задач кэширования. Сегодня мы поговорим о не менее часто встречающейся задаче – задаче логгирования и аудита. Нам часто приходится сталкиваться с такими ситуациями, как, например, анализ чужого кода. Представьте себе, что вам дали задачу интеграции с библиотекой стороннего производителя. Основной инструментарий чуть ли не каждого разработчика — .net reflector, ILSpy, dotPeek дают отличное представление о коде программы. О ее алгоритмах, структуре, возможных местах ошибок. И покрывают большой процент вопросов к программному продукту. Однако так происходит до тех пор, пока вы не начинаете ее активно использовать. Тут могут возникнуть как проблемы с производительностью, так и с непонятными «багами» внутри стороннего продукта, которые, если не иметь дизассемблера с функцией отладчика, не так-то просто найти. Или, например, вам необходимо просто следить за значениями переменных, не останавливая продукт в точках останова, real-time. Такие места часто необходимо срочно и быстро исправлять. А как при исправлении этого кода не написать программу, которая потом будет в топе сайта govnokod.ru? О таких ситуациях мы сейчас и поговорим.

Доброго времени суток, Хабр!

Спустя некоторое время решил вновь написать сюда и поделиться своим опытом. На этот раз статья будет о том, как кастомизировать стандартные валидаторы, и вызывать их там, где нам будет нужно, используя Spring — аспекты. Ну а сподвигло меня на написание — практически отсутствие подобной информации, особенно на русском.

Проблема

Итак, суть приложения примерно такова: есть gateway — api, который принимает запрос, а в дальнейшем модифицирует и перенаправляет его соответствующему банку. Вот только запрос для каждого из банков отличался — как и параметры валидации. Поэтому валидировать изначальный запрос не представлялось возможным. Тут было два пути — использовать аннотации из javax.validation, либо писать свой отдельный слой валидации. В первом случае была загвоздка — по умолчанию объекты можно валидировать только в контроллере. Во втором случае так-же были минусы — это лишний слой, большое количество кода, да и в случае изменения моделей, пришлось бы менять и валидаторы.

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

Дергаем валидаторы

Спустя пару часов копания в гугле были найдены пару решений, самое адекватное из которых было заавтовайрить javax.validation.Validator и вызвать у него метод validate, которому в качестве параметра нужно передать валидируемый объект.

Казалось бы, решение найдено, но автовайрить везде валидатор не казалось хорошей идеей, хотелось более элегантного решения.

Добавляем АОП

Недолго думая я решил попробовать адаптировать под это решение мною всеми любимые аспекты.

Логика была примерно следующей: создаём аннотацию, и вешаем её над методом который преобразует один объект в другой. Дальше в аспекте перехватываем все методы помеченные этой аннотацией и вызываем метод validate для возвращаемого ими значения. Профит.

Мои последние исследования, результат которых описан в предыдущих статьях, привели меня к мысли: а что, если создать систему, противоположную Системе подавления — Систему Раскрытия Потенциала, применимую к планете Земля и человечеству? Данная система описывает правила такого устройства многомерной среды обитания существ, в которой энтропия сознания сведена к минимуму. Живущие/играющие в ней существа реализуют весь доступный им Потенциал — совокупность всех их интеллектуальных, физических и всех прочих ресурсов, данных им во всём пространстве и времени, в полном объёме. Иначе говоря, как сделать идеальную игру?