Aspect Oriented Programming (AOP)

Аспектно ориентированное программирование? WTF!? Мало нам аббревиатур и концепций, подавай больше. На самом деле штука очень крутая и перспективная - расскажу в двух словах на примере C#.

Задача
Есть, допустим, репозиторий. К примеру UserRepository. Со стандартными CRUD операциями. Положить пользователя, вытащить по ID, удалить - ну вот это вот всё. И нужно вот нам собрать метрики - хотим видеть время выполнения каждого похода в субд.

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

Как это сделать?

Решение
1) Пойдём от решения "в лоб".

Пишем в начале каждого метода StopWatch.Start, а в конце StopWatch.ElapsedMilliseconds и пушаем метрику.

CreateUser(User user){
StopWatch sw = new StopWatch();
sw.Start();

//поход в базу

sw.Stop();
Metrics.Add('UserRepository.CreateUser',sw.ElapsedMs);
}

и что дальше? Будем нарушать DRY (don't repeat yourself) и вставлять данный кусок ВО ВСЕ МЕТОДЫ? Можно, но ... не можно. Очевидно, что нужно это куда-то выносить. Куда и как?

2) Окей, тут у нас развилочка по решениям. Более топорный способ - создадим базовый класс/хелпер, где сделаем метод-враппер, который будет в себя принимать некий Action (делегат), исполнять его и обернув тем же самым кодом - успокаиваемся. Или нет?

class RepositoryBase : {

CallWithMetric(Action act){
StopWatch sw = new StopWatch();
sw.Start();

act.Invoke();

sw.Stop();
Metrics.Add('UserRepository.CreateUser',sw.ElapsedMs);
}
}

и получается что-то такое :

CreateUser(User user){
CallWithMetric(() => {
//идём в базу
})
}

неплохо, но не сказать, что красиво. коллбековая джаваскриптщина какая-то.

3) Третья стадия уже более generic-like подход и в целом скорее уже ближе к AOP, хотя по факту скорее ООП.

Мы можем вынести из репозитория интерфейс и создать декоратор для репозитория. Оборачивать все репозитории им и "под капотом" вызывать метрики. Код приводить не буду, телега не предполагает длинных постов :) (можете глянуть на MSDN - понятная и коротенькая статейка).

Это уже взрослый подход. Но всё еще хочется немного магии.

3) И так. А вот и дошли до AOP. А что если нам создать атрибут, который будет сам оборачивать наш метод в нужный код? Звучит-то клёво, но как? Ведь атрибуты это про метаданные, они не являются декораторами сами по себе.

В C# есть пару классных библиотек. Самые известные это PostSharp и Fody. Они на этапе компиляции могут менять IL код. Это значит, вы можете пометить, допустим специальным атрибутом вам класс/метод и уже после компиляции в него вставится нужный код. В нашем случае - вызов метрик будет выглядеть уже как-то так :

[TimeElapsedMetric]
CreateUser(User user){
       //поход в базу      
}

Удобно. Красиво. Магия!

Но... есть нюансы :) Во-первых, PostSharp, говорят, хорош, но стоит по 700$ per developer. Цена - 🐴. Есть фри версия, но с ограничениями. Не интересно.

Fody же - бесплатный и с открытым кодом. Наш кейс он отлично покрывает (см. MethodTimer), + умеет навешивать "хуки" на методы из коробки. Но и тут есть нюансы. Например, он не позволяет делать re-execute методов, т.е. какой-нибудь Retry Policy уже не навесишь. Так же есть нюансы по работе с async/await - он не везде поддерживается и судя по вкладке Issues на гитхабе - есть баги.

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

Что ж. Штука классная, но ждём развития. Надеюсь, в ближайшие пару лет появится что-то "из-коробки".

Пара общих статей с рефами :
Aspect Oriented Programming (AOP) через исходный код
Теория и практика AOP. Как мы это делаем в Яндексе
Aspect-Oriented Programming : Aspect-Oriented Programming with the RealProxy Class

#csharp #библиотека_знаний #авторское