AspectJ, Spring, Maven

[voicer]

С выводом не согласен.
На мой взгляд, аспекты как раз-таки повышают читабельность кода за счет уменьшения «лишнего кода» (эм, как еще можно перевести boilerplate code? :) и за счет «сокрытия сложности» от конечного разработчика бизнес-логики.

Сравните сами:

public class TaskDao {
  Logger logger = Logger.getLogger("com.mycompany.dao.TaskDao");
  
  
  public void saveTask(Task task) {
    EntityManager em = EMF.getInstance().createEntityManager();
    EntityTransaction tx = null;
    try {
      tx = em.getTransaction();
      tx.begin();

      em.persist(task);

      tx.commit();
      logger.info("Successfully persisted task " + task.toString());
    }
    catch (RuntimeException e) {
      if ( tx != null && tx.isActive() ) tx.rollback();
      logger.error("Error while persisting task: " + e.getMessage());
    }
    finally {
      em.close();
    }
  }
}

* This source code was highlighted with Source Code Highlighter.

С:

@Component
@Transactional
public class TaskDao {
  @Logger
  Logger logger;
  @Autowired
  EntityManager em;
  
  
  public void saveTask(Task task) {
    em.persist(task);
    logger.info("Successfully persisted task " + task.toString());
  }
}

* This source code was highlighted with Source Code Highlighter.

Разумеется, если глянуть «под капот» аннотации, то сложность можно найти. Но достаточно разобраться лишь раз, что там происходит, и в последствии можно получить куда как более чистый и читабельный код без всяких побочных эффектов.
Я вообще не представляю себе современный проект на java без аннотаций.

[javax]

В Вашем примере — так оно и есть, согласен. Сформулирую иначе — легко сделать abuse.
Изменить поведение методов, добавить новые — это зло.

[voicer]

Ну тут надо следовать правилу большого пальца, на мой взгляд.
Если собираешься писать аннотацию, то надо быть точно уверенным, что она соответствует следующим условиям:

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

Если аннотация удовлетворяет этим требованиям, писать стоит. Если нет — надо еще семь раз подумать перед написанием :)

[norguhtar]

Вывод не верный :) Надо использовать аспекты там где они нужны. Для журнализирования и аудита самое то.

[javax]

Ок, изменю вывод. Убедили

[FlashXL]

У нас кэширование на аспектах сделано. Очень удобно и прозрачно получилось.

[javax]

Расскажите подробнее, если можно

[FlashXL]

Я, к сожалению, не автор сего креатива. Хотя может на досуге разберусь, оформлю топик.

[1nd1go]

mzungu-dev.livejournal.com/726.html — давненько написано, но пока Spring 3.1 в milestone, пользуемся.