Комментарии 7
"Всяк кулик свое болото хвалит"
автор, у тебя картинка с заголовка подписана "часть 1/2". Покажи вторую, пожалуйста!!!
Будет на неделе, в работе сейчас. Пингану по готовности)
Часть два: https://habr.com/ru/companies/haulmont/articles/1069308/ , лучше поздно, как говорится)))
Ты увидишь BaseEntity с id, createdDate и version. Увидишь AbstractCrudController<T, ID>, от которого наследуются все твои контроллеры. Увидишь самодельный слой прав — что-нибудь вроде @CheckPermission поверх PermissionEvaluator. Увидишь свой SoftDeleteRepository и аудит-слушатель на JPA-события.
Вообще ни разу не попал.
Наследование сущностей - самое тупое, что можно придумать. Даже если на старте это кажется хорошей идеей, то потом с этим будут проблемы. Нет никакой проблемы скопипастить 3 поля (продвинутые пользователи используют для этого сниппеты кода в IDE).
Контроллер - контракт взаимодействия с внешним миром. Если он для всех сущностей одинаковый, то нахрен не нужны 100500 контроллеров, сделай 1 и раздели маршрутизацию по сущностям.
Мы ж спринговое приложение рассматриваем, поэтому возьмём спринговый сесурити и не будем костылять.
Аудит-слушатель на JPA-события (именно как аудит, целью прописать кто/что сделал) не нужен примерно никогда. Аудит нужен на вызовы бизнес-операций, возможно, на всякие вызовы внешних сервисов с запросом данных, но только на JPA-события - эталонное НЕНУЖНО.
Если у тебя есть боевой Spring-проект старше двух лет без самопального BaseEntity, generic-CRUD и самодельного слоя прав внутри — брось ссылку в комментарии.
Я бы кинул, но ИБ будет против. Но ваш аргумент, конечно, уровня “сперва добейся”.
Спасибо, что по делу, такие комментарии приятно читать и отвечать на них.
Но мне показалось что в комменте вы, кажется, спорите не со статьёй: soft-delete и аудит на JPA вполне живые паттерны, много где применяются. Использовать их или нет, дело вкуса, согласен. Но антипаттерном я бы их не называл. Некоторые утверждают что Spring - opinionated, про него же мы не спорим)) Антипаттерн начинается там, где из всего набора вырастает целый самодельный фреймворк, что нужно и что не нужно, без возможности осознанного выбора и изменения в будущем.
А вот сниппет на три поля и один generic-контроллер по сущностям это уже как раз немного выглядик как антипаттерн, ИМХО: та самая конвенция и сантехника, которую в голове держит один человек. Так что спор похоже не мимо тезиса статьи, просто вы аккуратный разработчик.
Во второй части, если интересно продолжить обсуждение, как раз посмотрим, что налепит агент на голом Spring: не соберёт ли он свой Джеймикс сам, будет как минимум любопытно.
soft-delete … много где применяются
Пример? Из двух проектов, где я это выпиливал, это было говнорешением. И видя проблемы, которые оно приносило, я не вижу ни одной причины, где его использование было бы хоть как-то оправдано.
аудит на JPA
Как я и сказал ранее, не нужно, если только, конечно, это не тупой crud, без какой-либо логики. Таких проектов я ни разу не видел в реальной разработке.
Некоторые утверждают что Spring - opinionated
И они, в принципе, правы на все 146%. java-бэкэнд ≠ spring-приложение. Можно прекрасно обходиться и без него.
вырастает целый самодельный фреймворк … без возможности осознанного выбора и изменения в будущем.
Как бы перпендикулярные утверждения, нет? С чего это я не смогу внести изменения в свой код? И выбор писать своё, как раз таки более осознан, нежели тащить себе третьестороннюю зависимость с её багами, ограничениями и т.п.
сниппет на три поля
Вообще-то, я имел ввиду, 3 сниппета, т.к. не везде нужно версионирование и дата создания одновременно. Где-то достаточно чего-то одного, а где-то и ничего из этого.
один generic-контроллер по сущностям это уже как раз немного выглядик как антипаттерн
Антипаттерн - это плодить кучу одинаковых объектов (бинов) в памяти, без которых можно обойтись.
Ты уже написал свой Джеймикс, только плохой