Подход с пометкой всех методов @Transactional , помимо консистентности в ряде случаев, позволяет подгружать lazy поля. И да, не все поля можно подгрузить через join fetch за один проход (см. MultipleBagFetchException). Подозреваю, это главное, почему везде лепят транзакционность. У вас в примере этот аспект не затронут, а зря.
А потом - ну это неправильно говорить о двухкратном увеличении скорости работы методов на БД объемом в 6 строк. Если код работает 1мс и БД работает 1мс, то ускорение в 0.5мс - относительно существенное, но в абсолютных значениях оно ничтожно. Если БД отрабатывает 100мс и жава 5мс, и вы сэкономите разными приемами 10 мс, то это похвально, но при отсутствии highload'а это будет незаметно.
Сколько не пытался понять смысл подобного в Spring бэк-проектах, так и не смог. Выглядит усложнением, которое не приносит больших плюсов. Спринговый код и так во многих случаях основан на POJO и аннотациях, не сказал бы, что там есть сильная связанность по чему-то кроме интерфейсов. Захочешь подменить реализацию - это легко сделать. Чуть сложнее избавиться от ORM, но про ORM и тут не все понятно.
Плюс ко всему еще надо и новичков погружать в это, ломать устоявшиеся привычки.
Подход с пометкой всех методов
@Transactional, помимо консистентности в ряде случаев, позволяет подгружать lazy поля. И да, не все поля можно подгрузить через join fetch за один проход (см. MultipleBagFetchException). Подозреваю, это главное, почему везде лепят транзакционность. У вас в примере этот аспект не затронут, а зря.А потом - ну это неправильно говорить о двухкратном увеличении скорости работы методов на БД объемом в 6 строк. Если код работает 1мс и БД работает 1мс, то ускорение в 0.5мс - относительно существенное, но в абсолютных значениях оно ничтожно. Если БД отрабатывает 100мс и жава 5мс, и вы сэкономите разными приемами 10 мс, то это похвально, но при отсутствии highload'а это будет незаметно.
Сколько не пытался понять смысл подобного в Spring бэк-проектах, так и не смог. Выглядит усложнением, которое не приносит больших плюсов. Спринговый код и так во многих случаях основан на POJO и аннотациях, не сказал бы, что там есть сильная связанность по чему-то кроме интерфейсов. Захочешь подменить реализацию - это легко сделать. Чуть сложнее избавиться от ORM, но про ORM и тут не все понятно.
Плюс ко всему еще надо и новичков погружать в это, ломать устоявшиеся привычки.