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

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

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

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

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

Такого рода вещь не подходит очень часто, но каждый раз, когда она делает, monkeypatching ОЧЕНЬ полезен. Python также имеет декораторов, которые реализуют шаблон разработки Декоратора ( http://en.wikipedia.org/wiki/Decorator_pattern ) для выполнения подобных вещей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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