Используете ли вы AOP (Аспектно-ориентированное программирование) в производственном программном обеспечении?
АОП - интересная парадигма программирования на мой взгляд. Тем не менее, здесь еще не было дискуссий об этом в stackru (по крайней мере, я не смог их найти). Что ты думаешь об этом вообще? Используете ли вы АОП в своих проектах? Или вы думаете, что это скорее нишевая технология, которая не будет существовать долгое время или не сможет превратиться в мейнстрим (как это сделал ООП, по крайней мере, в теории;))?
Если вы используете AOP, пожалуйста, сообщите нам, какие инструменты вы используете. Спасибо!
11 ответов
Да.
Ортогональные проблемы, такие как безопасность, лучше всего решать с помощью перехвата в стиле АОП. Делается ли это автоматически (через что-то вроде контейнера внедрения зависимостей) или вручную, не имеет значения для конечной цели.
Один пример: атрибуты "before / after" в xUnit.net (проект с открытым исходным кодом, который я запускаю) являются формой перехвата методов в стиле AOP. Вы украшаете свои тестовые методы этими атрибутами, и непосредственно перед и после запуска этого тестового метода вызывается ваш код. Его можно использовать для таких вещей, как настройка базы данных и откат результатов, изменение контекста безопасности, в котором выполняется тест, и т. Д.
Другой пример: атрибуты фильтра в ASP.NET MVC также действуют как специализированные перехватчики методов в стиле AOP. Один, например, позволяет вам сказать, как следует обрабатывать необработанные ошибки, если они происходят в вашем методе действия.
Многие контейнеры для инъекций зависимостей, включая Castle Windsor и Unity, поддерживают это поведение либо "в коробке", либо с помощью расширений.
Python поддерживает AOP, позволяя вам динамически изменять его классы во время выполнения (что в Python обычно называется monkeypatching, а не AOP). Вот некоторые из моих случаев использования AOP:
У меня есть веб-сайт, на котором каждая страница генерируется функцией Python. Я хотел бы взять класс и сделать все веб-страницы, созданные этим классом, защищенными паролем. АОП приходит на помощь; перед вызовом каждой функции я делаю соответствующую проверку сеанса и перенаправляю при необходимости.
Я хотел бы сделать несколько журналов и профилирования для ряда функций в моей программе во время ее фактического использования. АОП позволяет мне рассчитывать время и распечатывать данные для файлов журнала без фактического изменения какой-либо из этих функций.
У меня есть модуль или класс, полный не поточнобезопасных функций, и я обнаружил, что использую его в каком-то многопоточном коде. Некоторые AOP добавляют блокировку этих вызовов функций без необходимости заходить в библиотеку и что-либо менять.
Подобные вещи появляются не очень часто, но всякий раз, когда это происходит, monkeypatching ОЧЕНЬ полезен. В Python также есть декораторы, которые реализуют шаблон проектирования Decorator ( http://en.wikipedia.org/wiki/Decorator_pattern) для выполнения подобных задач.
Обратите внимание, что динамически изменяемые классы могут также позволить вам обходить ошибки или добавлять функции в стороннюю библиотеку без фактического изменения этой библиотеки. Мне почти никогда не нужно это делать, но несколько раз, когда это происходит, это было невероятно полезно.
Я не понимаю, как можно справиться с такими сквозными проблемами, как ведение журнала, безопасность, управление транзакциями, чистая обработка исключений без использования AOP.
Любой, кто использует среду Spring (вероятно, около 50% разработчиков Java-приложений), использует AOP независимо от того, знают они это или нет.
В Terracotta мы довольно широко используем инструментарий AOP и байт-код для интеграции со сторонним программным обеспечением. Например, наша интеграция с Spring выполняется в значительной степени с помощью aspectwerkz. Короче говоря, нам нужно перехватывать вызовы бинов Spring и фабрик в различных точках для их кластеризации.
Таким образом, AOP может быть полезен для интеграции со сторонним кодом, который иначе нельзя изменить. Однако мы обнаружили, что существует огромная ловушка - если возможно, используйте только сторонние общедоступные API в своих точках соединения, в противном случае вы рискуете сломать свой код в результате изменения какого-либо частного метода в следующем вспомогательном выпуске, и он становится кошмар обслуживания.
AOP и разграничение транзакций - это совпадение, заключенное на небесах. Мы используем аннотации Spring AOP @Transaction, это делает более легким и интуитивно понятным разграничение тх, чем я когда-либо видел.
Мы использовали аспект J в одном из моих больших проектов в течение достаточно долгого времени. Проект состоял из нескольких веб-сервисов, каждый из которых имел несколько функций, которые были интерфейсом для сложной системы обработки документов / запросов. Где-то около 75 тысяч строк кода. Мы использовали аспекты для двух относительно небольших частей функциональности.
Сначала была трассировка потока приложений. Мы создали аспект, который выполнялся до и после каждого вызова функции, чтобы распечатать "введенную функцию" и "вышедшую функцию". С помощью функции выбора функции (возможно, pointcut? Я не помню правильное имя) мы смогли использовать это как инструмент отладки, выбирая только те функции, которые мы хотели отследить в данный момент времени. Это было действительно хорошее использование для аспектов в нашем проекте.
Второе, что мы сделали, - это показатели, специфичные для приложения. Мы помещаем аспекты в методы нашего веб-сервиса для сбора информации о времени, информации об объектах и т. Д. И сохраняем результаты в базе данных. Это было хорошо, потому что мы могли собирать эту информацию, но при этом держать весь этот код захвата отдельно от "реального" кода, который выполнил работу.
Я читал о некоторых хороших решениях, которые аспекты могут принести на стол, но я все еще не убежден, что они действительно могут сделать все, что вы не могли сделать (возможно, лучше) с "нормальной" технологией. Например, я не мог придумать ни одной важной функции или функциональности, в которой нуждался бы ни один из наших проектов, который не мог бы быть выполнен так же легко без аспектов - там, где я нашел аспекты полезными, были некоторые мелочи, которые я упомянул,
Основное приложение, над которым я работаю, включает в себя хост скриптов. AOP позволяет хосту проверять свойства скрипта, прежде чем решить, загружать скрипт или нет в домен приложения. Поскольку некоторые из сценариев довольно громоздки, это значительно ускоряет загрузку во время выполнения.
Мы также используем и планируем использовать значительное количество атрибутов для таких вещей, как управление компилятором, управление потоком и отладка в IDE, которые не обязательно должны быть частью окончательного распределенного приложения.
Мы используем AOP в нашем фасаде сеанса, чтобы предоставить нашим клиентам согласованную среду для настройки нашего приложения. Это позволяет нам выставить единую точку настройки без необходимости добавлять поддержку хуков вручную для каждого метода.
Кроме того, AOP предоставляет единую точку конфигурации для дополнительной настройки и удаления транзакций, а также для обычной регистрации. В общем, гораздо удобнее, чем делать все вручную.
Мы используем PostSharp для нашего решения АОП. У нас есть аспекты кэширования, обработки ошибок и повторных попыток базы данных, которые мы в настоящее время используем и в настоящее время делаем наши проверки безопасности Аспектом.
Отлично работает для нас. Разработчикам действительно нравится разделение интересов. Архитекторам очень нравится объединять логику уровня платформы в одном месте.
Библиотека PostSharp - это посткомпилятор, который выполняет внедрение кода. Он имеет библиотеку предопределенных перехватов, которые легко реализовать. Такое ощущение, что проводка в обработчиках событий.
Я интенсивно использую AOP в своих приложениях на C#. Я не большой поклонник необходимости использовать атрибуты, поэтому я использовал Castle DynamicProxy и Boo, чтобы применять аспекты во время выполнения, не загрязняя мой код
Да, мы используем АОП в прикладном программировании. Я предпочтительно использую AspectJ для интеграции aop в мои приложения Spring. Посмотрите на эту статью, чтобы получить более широкую перспективу для того же.
http://codemodeweb.blogspot.in/2018/03/spring-aop-and-aspectj-framework.html