Все проблемы с @Transactional от того, что его слишком просто прилепить на метод в сервисе, и оно даже будет работать. Но управление транзакцией - это не забота сервиса слоя бизнес-логики, этим должен заниматься инфраструктурный фасад, который и должен вызываться из контроллера.
Просто в большинстве примеров в этом фасаде по сути ничего, кроме @Transactional и делегирования вызова в сервис бизнес-логики не будет, поэтому его создание можно доверить спрингу, но при сложной бизнесовой логике, особенно, когда один бизнесовый метод может вызываться в разных ситуациях как самостоятельная операция или в рамках другой операции, лучше выделять инфраструктурные фасады явно.
А в чём проблема с final-классами? Я вижу только одну: создание прокси-объектов во время исполнения spring-ом и подобными фреймворками/библиотеками.
По-моему, в первую очередь в таком случае следует задаться вопросом, может не зря класс зафинален, какие причины побудили автора сделать именно так, а не иначе.
Фраза представляет собой словесный палиндром, то есть может читаться как слева направо, так и, по словам, справа налево. Кроме того, фразу можно написать двумя способами: «Мы — не рабы, рабы — не мы» и «Мы — не рабы, рабы немы» — то есть мы не рабы потому, что не немые.
О чём, собственно, и написано в заключительной части статьи.
Redis принципиально занимает другую нишу, чем PostgreSQL, и выделяется в том, к чему PostgreSQL не стремится. Примеры включают кэширование данных с TTL, а также хранение и обработку эфемерных данных.
P.S. Возможно этот абзац был добавлен после Вашего комментария, в таком случае, прошу прощения.
Туда им и дорога, сколько ни брал мышей от Genius, у всех одна и та же проблема: через два-три месяца скролл начинает скакать вверх-вниз.
А что по этому поводу думает товарищ @lany?
Так-то это было видео. :)
Пишешь текст;
выделяешь;
появляется всплывающее меню;
тыкнуть в иконку гиперссылки;
заполнить верхнее поле ввода ссылкой, при необходимость в нижнем поле поправить текст.
P.S. Поведение ни разу не интуитивное и дико бесит.
Затем же, зачем и Math.abs(). Автор не в курсе про существование метода.
А текст-то, похоже, отсюда. Пусть и с небольшими правками.
Ничего подобного. В одном файле может быть сколько угодно классов. Даже не вложенных. В 1 файле не может быть более одного публичного класса.
Что значит "зачем"? Бюджет освоить.
А если серьёзно, то вряд ли кто-то из законописцев знает что так можно. А Вы ещё и подсказываете.
А чем не подошёл MapStruct?
Отладка должна выполняться в тестах (модульных, интеграционных), перезапустить которые не занимает много времени.
Параметры в java всегда передаются по значению. Просто не стоит забывать, что значением объектных типов является ссылка.
Все проблемы с
@Transactionalот того, что его слишком просто прилепить на метод в сервисе, и оно даже будет работать. Но управление транзакцией - это не забота сервиса слоя бизнес-логики, этим должен заниматься инфраструктурный фасад, который и должен вызываться из контроллера.Просто в большинстве примеров в этом фасаде по сути ничего, кроме @Transactional и делегирования вызова в сервис бизнес-логики не будет, поэтому его создание можно доверить спрингу, но при сложной бизнесовой логике, особенно, когда один бизнесовый метод может вызываться в разных ситуациях как самостоятельная операция или в рамках другой операции, лучше выделять инфраструктурные фасады явно.
Именно, что "кажется". Какой процент ныне работающих останется на работе, если их доход останется на прежнем уровне без необходимости работать.
У людей появится куча свободного времени, которое можно посвятить хобби, семье, всяким штукам, на которые всегда не хватает времени.
Для полноты картины надо бы добавить к сравнению Servlet 3.1 имплементацию Spring MVC.
По-моему, в первую очередь в таком случае следует задаться вопросом, может не зря класс зафинален, какие причины побудили автора сделать именно так, а не иначе.
P.S. Возможно этот абзац был добавлен после Вашего комментария, в таком случае, прошу прощения.