Здравствуйте, IT, Вы писали:

IT>Понятно. Как обычно вся дискуссия крутится вокруг формулировок Тогда давай формулировать.
IT>Классический АОП предполагает, что как разработку, так и модификацию метода средствами АОП осуществляет сам разработчик метода по его волеизлиянию. С помощью интерсепторов метод меняется во время его вызова по желанию того, кто этот метод использует. Это тоже вполне валидный сценарий, не вижу в этом ничего плохого, но всё же это другое.
Не-не. Не путай цели и средства. Цель АОП — описывать аспекты кода. Т.е. задаём аспект "Вызов методов в слое DAO должен оборачиваться в DB-транзацкцию, для 'Load*' транзакция должна быть RO, для 'Save*' — RW". Теперь кто бы ни позвал Save или Load метод любого класса DAO — транзакция будет открыта и закрыта, с нужными пермишеннами.
Каким способом это добиваться — дело другое. Работающие варианты тут были упомянуты — генерировать обёртки вокруг классов, манипулировать байткодом во время компиляции или загрузки, создавать динамические прокси и т.п. И эти все варианты будут работать. InterceptsLocation — работать не будет.

IT>Немного шарма во всё это вот добавляет то, что в 95% случаев разработчик метода и его пользователь — это один и тот же человек/команда, которым абсолютно по барабану разница между АОП и интерсепторами, т.к. в этом случае результат тот же самый.
IT>Но в принципе да. АОП через интерсепторы, это АОП слегка через жопу, хотя и не очень заметно и вполне употребимо. Задачу решает? Решает. В продакшин!
Ок... Могу согласится, что это заработает на небольшом одномодульном проекте, без единой 3rd party зависимости. Ну там небольшую консольную утилитку состряпать.
Впрочем в этом случае возникнет вопрос — накой в небольшом одномодульном проекте одного человека нужен АОП?!

Здравствуйте, IT, Вы писали:

IT>Понятно. Как обычно вся дискуссия крутится вокруг формулировок Тогда давай формулировать.
IT>Классический АОП предполагает, что как разработку, так и модификацию метода средствами АОП осуществляет сам разработчик метода по его волеизлиянию. С помощью интерсепторов метод меняется во время его вызова по желанию того, кто этот метод использует. Это тоже вполне валидный сценарий, не вижу в этом ничего плохого, но всё же это другое.
Не-не. Не путай цели и средства. Цель АОП — описывать аспекты кода. Т.е. задаём аспект "Вызов методов в слое DAO должен оборачиваться в DB-транзацкцию, для 'Load*' транзакция должна быть RO, для 'Save*' — RW". Теперь кто бы ни позвал Save или Load метод любого класса DAO — транзакция будет открыта и закрыта, с нужными пермишеннами.
Каким средством это добиваться — дело другое. Работающие варианты тут были упомянуты — генерировать обёртки вокруг классов, манипулировать байткодом во время компиляции или загрузки, создавать динамические прокси и т.п. И эти все варианты будут работать. InterceptsLocation — как средство, не подходит.

IT>Немного шарма во всё это вот добавляет то, что в 95% случаев разработчик метода и его пользователь — это один и тот же человек/команда, которым абсолютно по барабану разница между АОП и интерсепторами, т.к. в этом случае результат тот же самый.
IT>Но в принципе да. АОП через интерсепторы, это АОП слегка через жопу, хотя и не очень заметно и вполне употребимо. Задачу решает? Решает. В продакшин!
Ок... Могу согласится, что это заработает на небольшом одномодульном проекте, без единой 3rd party зависимости (включая стандартную библиотеку Платформы). Ну там небольшую консольную утилитку состряпать.
Впрочем в этом случае возникнет вопрос — накой в небольшом одномодульном проекте одного человека нужен АОП?!