Используете ли вы AOP (Aspect Oriented Programming) в производственном программном обеспечении?

Question

AOP - интересная парадигма программирования, на мой взгляд. Тем не менее, здесь еще не было дискуссий об этом в stackoverflow (по крайней мере, я не смог их найти). Что ты думаешь об этом вообще? Используете ли вы АОП в своих проектах? Или вы думаете, что это скорее нишевая технология, которая не будет существовать долгое время или не станет популярной (как ООП, по крайней мере, в теории;))?

Если вы используете AOP, пожалуйста, сообщите нам, какие инструменты вы также используете. Спасибо!

Answer 1

Python поддерживает AOP, позволяя динамически изменять его классы во время выполнения (что в Python обычно называется monkeypatching, а не AOP). Вот некоторые из моих случаев использования AOP:

1. У меня есть веб-сайт, на котором каждая страница генерируется функцией Python. Я хотел бы взять класс и сделать все веб-страницы, созданные этим классом, защищенными паролем. АОП приходит на помощь; перед вызовом каждой функции я делаю соответствующую проверку сеанса и перенаправляю при необходимости.

2. Я хотел бы сделать несколько журналов и профилирования для ряда функций в моей программе во время ее фактического использования. АОП позволяет мне рассчитывать время и распечатывать данные для файлов журнала без фактического изменения любой из этих функций.

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

Подобные вещи возникают не очень часто, но всякий раз, когда это происходит, мартышка очень полезна. В Python также есть декораторы, которые реализуют шаблон проектирования Decorator (http://en.wikipedia.org/wiki/Decorator_pattern) для выполнения подобных задач.

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

Answer 2

Да.

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

Один пример: атрибуты "before / after" в xUnit.net (проект с открытым исходным кодом, который я запускаю) являются формой перехвата методов в стиле AOP. Вы украшаете свои тестовые методы этими атрибутами, и непосредственно перед и после запуска этого тестового метода вызывается ваш код. Его можно использовать для таких вещей, как настройка базы данных и откат результатов, изменение контекста безопасности, в котором выполняется тест и т. Д.

Другой пример: атрибуты фильтра в ASP.NET MVC также действуют как специализированные перехватчики методов в стиле AOP. Одна, например, позволяет вам сказать, как следует обрабатывать необработанные ошибки, если они происходят в вашем методе действия.

Многие контейнеры для внедрения зависимостей, в том числе Castle Windsor и Unity, поддерживают это поведение «в коробке» или с помощью расширений.

Answer 3

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

Любой, кто использует среду Spring (вероятно, около 50% разработчиков Java-приложений), использует AOP независимо от того, знают они это или нет.

Answer 4

AOP и разграничение транзакций - это совпадение, заключенное на небесах. Мы используем аннотации Spring AOP @Transaction, это делает более легким и интуитивно понятным разграничение тх, чем я когда-либо видел.

Answer 5

На Терракотовая мы довольно широко используем инструментарий AOP и байт-код для интеграции со сторонним программным обеспечением и инструментами. Например, наша пружинная интеграция в значительной степени достигается с помощью aspectwerkz . Короче говоря, нам необходимо перехватывать вызовы бинов Spring и фабрик в различных точках для их кластеризации.

Таким образом, AOP может быть полезен для интеграции со сторонним кодом, который иначе нельзя изменить. Однако мы обнаружили, что существует огромная ловушка - если это возможно, используйте только сторонние общедоступные API в своих точках соединения, в противном случае вы рискуете сломать ваш код в результате изменения какого-либо частного метода в следующем вспомогательном выпуске, и он становится кошмар обслуживания.

Answer 6

Мы использовали aspectJ в одном из моих больших проектов довольно долгое время. Проект состоял из нескольких веб-сервисов, каждый с несколькими функциями, которые были интерфейсом для сложной системы обработки документов / запросов. Где-то около 75 тысяч строк кода. Мы использовали аспекты для двух относительно небольших частей функциональности.

Сначала была трассировка потока приложения. Мы создали аспект, который выполнялся до и после каждого вызова функции, чтобы распечатать «введенную функцию» и «вышедшую функцию». С помощью функции выбора функции (возможно, pointcut? Я не помню правильное имя) мы смогли использовать это как инструмент отладки, выбирая только те функции, которые мы хотели отследить в данный момент времени. Это было действительно хорошее использование для аспектов в нашем проекте.

Второе, что мы сделали, - это показатели, специфичные для приложения. Мы помещаем аспекты в методы нашего веб-сервиса для сбора информации о времени, информации об объектах и ​​т. Д. И сохраняем результаты в базе данных. Это было хорошо, потому что мы могли собирать эту информацию, но при этом держать весь этот код захвата отдельно от «реального» кода, который выполнил работу.

Я читал о некоторых хороших решениях, которые аспекты могут принести к столу, но я все еще не уверен, что они действительно могут сделать все, что вы не могли сделать (возможно, лучше) с "нормальной" технологией. Например, я не мог придумать ни одной важной функции или функциональности, в которой нуждался бы ни один из наших проектов, которые не могли бы быть выполнены так же легко без аспектов - там, где я нашел аспекты полезными, были некоторые мелочи, которые я упомянул .

Answer 7

Мы используем PostSharp для нашего решения АОП. У нас есть аспекты кэширования, обработки ошибок и повторных попыток базы данных, которые мы в настоящее время используем и в настоящее время делаем наши проверки безопасности аспектом.

Отлично работает для нас. Разработчикам действительно нравится разделение интересов. Архитекторам очень нравится объединять логику уровня платформы в одном месте.

Библиотека PostSharp - это посткомпилятор, который выполняет внедрение кода. Он имеет библиотеку предопределенных перехватов, которые легко реализовать. Такое ощущение, что проводка в обработчиках событий.

Answer 8

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

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

Answer 9

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

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

Answer 10

Я интенсивно использую AOP в своих приложениях на C #. Я не большой поклонник необходимости использовать атрибуты, поэтому я использовал Castle DynamicProxy и Boo для применения аспектов во время выполнения без загрязнения моего кода