AOP - это интересная парадигма программирования, на мой взгляд. Однако об этом еще не было обсуждений в stackoverflow (по крайней мере, я не смог их найти). Что вы думаете об этом вообще? Вы используете АОП в своих проектах? Или вы считаете, что это скорее нишевая технология, которая не будет существовать долгое время или не будет входить в основное русло (например, ООП, по крайней мере, теоретически;))?
Если вы используете AOP, сообщите нам, какие инструменты вы используете. Спасибо!
Да.
Ортогональные проблемы, такие как безопасность, лучше всего делать с перехватом AOP-стиля. Независимо от того, выполняется ли это автоматически (через нечто вроде контейнера для инъекций зависимостей) или вручную, не имеет значения для конечной цели.
Один пример: атрибуты "до/после" в xUnit.net (проект с открытым исходным кодом, который я запускаю) являются формой AOP- стиль метод перехват. Вы украшаете свои методы тестирования этими атрибутами, и как раз до и после этого метода тестирования вызывается ваш код. Он может использоваться для таких вещей, как настройка базы данных и откат результатов, изменение контекста безопасности, в котором проходит тест, и т.д.
Другой пример: атрибуты фильтра в ASP.NET MVC также действуют как специализированные перехватчики методов в стиле AOP. Один, например, позволяет вам сказать, как обрабатывать необработанные ошибки, если они происходят в вашем методе действий.
Многие контейнеры для инъекций зависимостей, включая Castle Windsor и Unity, поддерживают это поведение либо "в коробке", либо с помощью расширений.
Python поддерживает AOP, позволяя динамически изменять его классы во время выполнения (что в Python обычно называется monkeypatching, а не AOP). Вот некоторые из моих вариантов использования АОП:
У меня есть сайт, на котором каждая страница создается функцией Python. Я хотел бы взять класс и сделать все веб-страницы, созданные этим классом с защитой паролем. АОП приходит на помощь; перед вызовом каждой функции я выполняю соответствующую проверку сеанса и при необходимости перенаправляю.
Я хотел бы сделать некоторые записи и профилирование на кучу функций в моей программе во время ее фактического использования. AOP позволяет мне рассчитать синхронизацию и распечатать данные в файлах журналов без фактической модификации любой из этих функций.
У меня есть модуль или класс, полный функций, не связанных с потоком, и я нахожу, что я использую его в некотором многопоточном коде. Некоторые AOP добавляет блокировку этих вызовов функций, не заходя в библиотеку и ничего не меняя.
Такие вещи возникают не очень часто, но всякий раз, когда это происходит, monkeypatching ОЧЕНЬ полезен. Python также имеет декораторы, которые реализуют шаблон дизайна Decorator (http://en.wikipedia.org/wiki/Decorator_pattern), чтобы выполнить аналогичные вещи.
Обратите внимание, что динамически модифицирующие классы также могут работать с ошибками или добавлять функции в стороннюю библиотеку, не изменяя при этом эту библиотеку. Мне почти никогда не нужно это делать, но несколько раз это было невероятно полезно.
Я не понимаю, как можно обрабатывать сквозные проблемы, такие как ведение журнала, безопасность, управление транзакциями, обработка исключений чистым способом без использования АОП.
Любой, кто использует структуру Spring (возможно, около 50% разработчиков Java-приложений), использует AOP, знают ли они это или нет.
В Terracotta мы используем AOP и инструментарий байт-кода довольно широко, чтобы интегрироваться с программным обеспечением стороннего разработчика и инструментом. Например, Spring intergration выполняется в значительной степени с помощью aspectwerkz. В двух словах нам нужно перехватить вызовы на Spring beans и bean заводы в разных точках, чтобы сгруппировать их.
Таким образом, АОП может быть полезен для интеграции с сторонним кодом, который в противном случае не может быть изменен. Тем не менее, мы обнаружили, что существует огромная ловушка - если это возможно, используйте только сторонний публичный API в своих точках соединения, иначе вы рискуете сломать свой код путем изменения какого-либо частного метода в следующей младшей версии, и это станет кошмар для обслуживания.
АОП и демаркация транзакций - это матч, совершенный на небесах. Мы используем аннотации Spring AOP @Transaction, это упрощает и интуитивно понятное tx-демаркацию, чем я когда-либо видел где-либо еще.
Мы использовали aspectJ в одном из моих больших проектов в течение довольно долгого времени. Проект состоял из нескольких веб-сервисов, каждый из которых имел несколько функций, которые были интерфейсом для сложной системы обработки/обработки документов. Где-то около 75 тыс. Строк кода. Мы использовали аспекты для двух относительно небольших частей функциональности.
Сначала был отслеживание потока приложений. Мы создали аспект, который выполнялся до и после каждого вызова функции для печати "введенных" функций "и" выведенных "функций". С помощью функции селекторной функции (pointcut может быть? Я не помню правильного имени) мы могли использовать это как инструмент отладки, выбирая только функции, которые мы хотели отслеживать в данный момент. Это было очень приятно использовать для аспектов нашего проекта.
Второе, что мы сделали, это метрики приложения. Мы ставим аспекты вокруг наших методов веб-сервисов для сбора времени, информации об объектах и т.д. И дампа результатов в базе данных. Это было приятно, потому что мы могли захватить эту информацию, но все же сохранить весь этот код захвата отдельно от "реального" кода, который выполнял работу.
Я читал о каких-то хороших решениях, которые аспекты могут принести в таблицу, но я до сих пор не убежден, что они действительно могут делать все, что вы не могли бы сделать (может быть, лучше) с "нормальной" технологией. Например, я не мог придумать какой-либо важной функции или функциональности, которые необходимы для любого из наших проектов, которые не могут быть выполнены так же легко без каких-либо аспектов, - где я нашел полезные аспекты, - это те незначительные вещи, которые я упомянул.
Я сильно использую AOP в своих приложениях С#. Я не большой поклонник использования атрибутов, поэтому я использовал Castle DynamicProxy и Boo для применения аспектов во время выполнения без загрязнения моего кода.
Мы используем AOP на нашем сеансе, чтобы обеспечить согласованную структуру для наших клиентов, чтобы настроить наше приложение. Это позволяет нам разоблачить единую точку настройки без необходимости добавлять ручную поддержку крюка для каждого метода.
Кроме того, АОП предоставляет единую точку конфигурации для дополнительной настройки и списания транзакций и обычных событий ведения журнала. Все сказано, гораздо удобнее, чем делать все это вручную.
Основное приложение, в котором я работаю, включает хост script. AOP позволяет хосту проверять свойства script, прежде чем решать, загружать ли script в домен приложения. Поскольку некоторые сценарии довольно громоздки, это приводит к значительно более быстрой загрузке во время выполнения.
Мы также используем и планируем использовать значительное количество атрибутов для таких вещей, как управление компилятором, управление потоком и отладка в IDE, которые не обязательно должны быть частью окончательного распределенного приложения.
Мы используем PostSharp для нашего решения AOP. У нас есть операции кэширования, обработки ошибок и повторной загрузки баз данных, которые мы в настоящее время используем, и в процессе проверки безопасности Аспект.
Отлично работает для нас. Разработчики действительно любят разделение проблем. Архитекторам очень нравится иметь логику уровня платформы, объединенную в одном месте.
Библиотека PostSharp - это пост-компилятор, который выполняет инъекцию кода. У этого есть библиотека предопределенных перехватов, которые мертвы мозги, легко реализуемые. Это похоже на проводку в обработчиках событий.