Комментарии 23
Абсолютно не читабельно.
Перевод нечитабелен, а само АОП — это исчадье ада, которое я никому не рекомендую использовать. Давайте дождемся C#5, а?
Не так давно Вы писали что любите АОП и PostSharp в частности :)
Не буду голословным: Несколько полезных аспектов для PostSharp
Ага. Вы так говорите про АОП, пушто MS не выпустили msbuild с АОП-тасками. Выпустят — будете рекомендовать всем. А приложения с БД не будем писать, пока не появится новый Entity Framework. И до изобретения LINQ не стоило и браться писать запросы. И вообще, в код не будем лазать, пока не выпустят новый Resharper…
Проблема в том, что PostSharp полностью въедается в ваш код, и потом его уже оттуда не выудить.
По-моему это его назначение. Тут просто надо понимать, где его надо использовать, а где-нет. Например, какие-то аспекты используются только в debug версии, на основе других — основывается функционал продукта (например, SmartInspect, Gibraltar)… Это как с любой технологией. Если ее использовать где ни попадя, то в итоге, конечно, приходишь к выводу что «не то»…
АОП != PostSharp. Вы же нападаете на AOP. Не нравится этот инструмент — берите другой, с неинтрузивной разметкой JoinPoints и т.п.
… Кстати правда. Столкнулся сегодня с проблемой, когда дебагер отказывался показывать информацию о переменных в foreach циклах! Решилось все отключением PostSharp. Так как проект новый-решил вообще пока отказаться от этого инструмента. Удобства есть, но скрытые камни мне не нужны =(
По моему цель этой статьи привести ссылку на главных конкурентов АОП. Правда по куче противопоказаний это становится утвержденем, что конкурентов у АОП все еще нет.
НЛО прилетело и опубликовало эту надпись здесь
Написал «ответ» на этот пост: habrahabr.ru/blogs/net/123222/
Все таки нужно отделять котят от котлет — АОП это парадигма, а DI это шаблон проектирования. АОП служит более фундаментальной цели — избавится от зависимости между разными компонентами системы совместно решающих одну задачу, и для решения фундаментальной проблемы ООП как «хрупкий базовый класс». Это главная проблема всех парадигм с повторно используемым кодом. Как гарантировать работоспособность системы при изменении любого компонента системы? Без рефакторинга и ревизий. Эта проблема решается сложными фреймворками и технологиями, но единого принципа нет. Очень схожей по сути, но более фундаментальной, является компонентная парадигма Вирта. Не удивительно, что АОП появилась в Xerox PARC, последнее место работы Вирта до его выхода на пенсию в 99.
Вы абсолютно правы! Целью этой статьи было как раз внести ясность, что АОП — это не DI, как многие полагают, а нечто большее, что стоит изучать, в чем стоит «набивать руку». Что это нечто большее чем просто концепт. Если сходить на сайт производителей, то можно убедиться что у того же PostSharp очень много именитых заказчиков. Это серьезная платформа, которая пока что не очень распространена в России.
Применяется ли АОП в скриптовых языках типа Perl, PHP, Python, Ruby (в алфавитном порядке), как реальный инструмент оптимизации процессов разработки или он актуален только для компилируемых языков со строгой статической типизацией?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PostSharp. Аспектно-ориентированное программирование vs Dependency Injection