Прошу поделиться опытом, мыслями по поводу использования аспектно-ориентированного подхода при разработке проектов.
Какие преимущества/недостатки привносит "подключение" аспектов к J2EE проекту?
Если использовался АО подход, какой фреймворк применялся?

Сам не применял, но надеюсь добраться :-)
Далее пошло мое ИМХО
Все преимущества описаны в статьях на тему АОП. Там же можно найти недостатки этой технологии.
Недостатки реализаций - не всякая IDE поддерживает АОП и еще менее всякая поддерживает то АОП, которое реализованно в любимом контейнере. Пример - JBoss (мой любимый контейнер) сваял свое АОП, Intellij IDEA поддерживает AspectJ.
К тому же сейчас нет стандартной спецификации на АОП и прикрутив его к приложению мы практически гарантированно теряем переносимость (хотя я не уверен, что она была :-D )

Спасибо за ответ.

Цитата(sandello @ 29.8.2005, 07:07)

Все преимущества описаны в статьях на тему АОП. Там же можно найти недостатки этой технологии.

Если можно, прошу сообщить линки на статьи с недостатками. О преимуществах я имею представление, но хотелось бы представить картину во всей ее полноте.

Цитата(sandello @ 29.8.2005, 07:07)

Недостатки реализаций - не всякая IDE поддерживает АОП и еще менее всякая поддерживает то АОП, которое реализованно в любимом контейнере. Пример - JBoss (мой любимый контейнер) сваял свое АОП, Intellij IDEA поддерживает AspectJ.

Про поддержку AspectJ в Intellij IDEA, к сожалению, ничего не знаю. Зато могу отметить, что к Eclipse существуют плагины, как для AspectJ, так и для JBoss AOP.
Также плагины поддержки AspectJ существуют для JBuilder, JDeveloper, NetBeans, Emacs, но они, судя по всему, не находятся в фазе активного развития (поддерживаемая версия AspectJ 1.0.6 - 1.1.1). Возможно их развитие продолжится после выхода новой версии AspectJ 1.5.

Цитата(sandello @ 29.8.2005, 07:07)

К тому же сейчас нет стандартной спецификации на АОП и прикрутив его к приложению мы практически гарантированно теряем переносимость (хотя я не уверен, что она была  :-D )

О какой переносимости идет речь? Если мы используем Struts, мы также "теряем переносимость", когда пробуем перейти, к примеру, на WebWorks.

На тему недостатков: надо просто читать внимательно статьи (например http://www.javable.com/columns/aop/workshop/02/) и пытаться понять, что из этого следует. Сразу скажу, что сам этого толком не делал :-)

По моим сведеньям, поддержка AspectJ в IDEA есть. Включается отдельным параметром при старте. Кажется -Didea.aspectj.support=enabled

На тему переносимости: J2EE - стандарт. Поэтому можно написать приложение так, что оно будет работать в практически любом контейнере с минимумом телодвижений. На AOP стандарта нету. Соответственно, нужно писать под конкретную реализацию. В этом случае ни о какой переносимости речи нет.

Использование какого-либо framework'а сразу решает вопрос о переносимости отрицательно. Это надо просто помнить при выборе стратегии создания приложения.

Цитата(sandello @ 30.8.2005, 09:53)

Использование какого-либо framework'а сразу решает вопрос о переносимости отрицательно.

sandello, не надо путать теплое с мягким.

Использование того или иного фреймворка - есть объективная необходимость для любого проекта масштаба чуть крупнее домашней странички. Почему? Потому что любое приложение опирается на работу множества вспомогательных служб: конфигурация, стартап, логирование, пул датабазных соединений, служба каталогов, мапинг ресурсов, персистенция, управление транзакциями, и т. д., и т. п.

Можно, конечно, не использовать никакого фреймворка, а написать свою собственную среду выполнения - и это тоже вполне валидный подход. Но вот ведь какая штука: когда ты закончишь написание такой среды, то обнаружишь, что, сам того не подозревая, разработал просто еще один фреймворк - свой собственный. Он может быть лучше или хуже других, но твое приложение будет точно так же замкнуто на нем (locked-in), как если бы ты использовал Cocoon или Tapestry или Spring или любой другой из миллиона имеющихся фреймворков.

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

Так штаааа

Цитата(sandello @ 30.8.2005, 09:53)

На тему недостатков: надо просто читать внимательно статьи (например http://www.javable.com/columns/aop/workshop/02/) и пытаться понять, что из этого следует. Сразу скажу, что сам этого толком не делал :-)

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

Цитата(sandello @ 30.8.2005, 09:53)

На тему переносимости: J2EE - стандарт. Поэтому можно написать приложение так, что оно будет работать в практически любом контейнере с минимумом телодвижений. На AOP стандарта нету. Соответственно, нужно писать под конкретную реализацию. В этом случае ни о какой переносимости речи нет. Использование какого-либо framework'а сразу решает вопрос о переносимости отрицательно. Это надо просто помнить при выборе стратегии создания приложения.

Не согласен с этим. Всякая "переносимость" не существует сама по себе. Она существует в каких-либо рамках, например переносимость приложения в рамках стандарта J2EE. И если используемый фреймворк позволяет создавать приложение, которое также соответствует нотациям данного стандарта, то приложение будет также "переносимым".
Но к теме данного топика это не относится

Цитата(Stampede @ 30.8.2005, 20:06)

Использование того или иного фреймворка - есть объективная необходимость для любого проекта масштаба чуть крупнее домашней странички. Почему? Потому что любое приложение опирается на работу множества вспомогательных служб: конфигурация, стартап, логирование, пул датабазных соединений, служба каталогов, мапинг ресурсов, персистенция, управление транзакциями, и т. д., и т. п. Но при этом надо отдавать себе отчет в том, что замыкая себя на каком-либо фреймворке, мы не поступаемся переносимостью в широком смысле этого слова, ибо все фреймворки в конечном итоге приводятся к наименьшему общему знаменателю под названием J2EE - что гарантирует работоспособность нашего приложения поперек (across) множественных контейнеров и аппаратных платформ. А это и есть именно то, что волнует людей больше всего, когда они произносят слово "переносимость". Так штаааа

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

А куда? Я прописал в idea.properties - всё осталось по прежнему...

Есть, вроде, два похожих плагина "AspectJ Weaver" и "AspectWerkz plugin", но к ним нет никакой доки и мне не удалось разобраться, как они работают. В настройках появляется пунктик, который выводит сообщение, что прежде чем работать с аспектами, они уже должны быть откомпилированы - зачем, спрашивается? Откомпилить и запустить я итак смогу... Ссылаются они на сайт на немецком языке (кнопка "eng" в нём есть, но ведёт на страничку "under constraction").

Короче, кто-нибудь знает, как IDEA 6.0 заставить работать с AspectJ? Мне бы хотя бы подсветочку синтаксиса нормальную...


Когда нет стандарта де-юре, появляется стандарт де-факто. Фактически, на аспекты есть стандарт де-факто - AspectJ.

Так штаааа... 

В АОП у нас есть конкретное удобство - с помощью Spring мы описываем бин, который окружает методы с определенным названием транзакцией. Очень удобно.

Есть вопрос: а как у вас с отладкой? И с диагностикой ошибок?
Я для себя вывел два недостатка реализаций AOP:

• затруднённая отладка и диагностика ошибок;
• кривые библиотеки для модификации байт-кода.

Это сообщение отредактировал(а) w1nd - 2.11.2006, 10:38