Spring AOP против аннотации @Transactional

Я сам задавался этим вопросом. Я нашел хорошее обсуждение этой темы на Весенний форум.

Ниже я резюмирую свои выводы из вышеупомянутой ссылки:

Демаркация транзакций АОП

Выгоды:

• Код Java лишен конфигурации транзакции, которая вместо этого содержится вне кода в файлах конфигурации.
• Код Java не имеет прямых зависимостей от библиотек Spring.
• Управление транзакциями централизовано в одном месте
• Может применять границы транзакций к исходному коду, который вы не можете легко изменить

Недостатки:

• Сложность АОП. Только из кода не будет ясно, где лежат границы транзакций, и разработчики могут непреднамеренно нарушить транзакции, например, изменив сигнатуры методов, где применяется pointcut.
• Необходимость коснуться двух мест (исходный код и конфигурация AOP), чтобы применить границы транзакций.

@Transactional Весенняя аннотация

Выгоды:

• Границы транзакций становятся более ясными при изучении исходного кода.

Недостатки:

• Код Java связан с объявлением транзакции (пусть только на уровне метаданных, но все же требуется импорт Spring).

Обсуждение напоминает мне аннотации JPA и XML-конфигурацию JPA. С конфигурацией JPA на основе XML сущности «чище», но стоит ли разделение усилий? Или, возможно, даже вредно ли разделение (хорошо иметь возможность открыть исходный файл Java и сразу узнать, основываясь на аннотации @Entity, что класс является EJB)? На практике мне кажется, что большинство разработчиков предпочитают использовать аннотации JPA. Хотя в этом случае, в отличие от @Transactional, аннотации jpa являются стандартом, так что это может помочь решить некоторые проблемы.

Тем не менее, я участвовал в проектах, в которых мы использовали конфигурацию AOP Spring для аннотирования перехватчика Struts2 (веб-работы), чтобы разрешить одну транзакцию на запрос, и это сработало отлично. В этом случае мы не особенно беспокоились о границах транзакций на нашем сервисном уровне или где-либо еще — все уже участвовало в транзакции, и поскольку представление отображалось до того, как перехватчик закрыл транзакцию, не было необходимости применять OpenSession/EntityManagerInView решение.