Меня зовут Аксёнов Вячеслав, я бэкенд разработчик и в последние годы пишу веб приложения на java/kotlin. За всю свою практику я встречался с различными системами как в продакшене, так и в пет проектах. Некоторые системы имели свои “велосипеды”, но большинство базировались на очень похожих технических решениях.
Основная идея этой статьи описать основные технические задачи, которые ставятся перед современными веб приложениями. А также перечислить те фреймворки и библиотеки, которые чаще всего используются для решения этих задач. Бонусом захватим немного инфраструктуры.
Таким образом новички, которые не знаю чего им ждать от корпоративной разработке или в каком фреймворке подтягивать свои навыки, смогут увидеть картину мира чуть шире и сделать правильный выбор.
Какие технические задачи бывают?
Для начала давайте разберем какие самые распространенные проблемы и задачи ставятся перед современными веб приложениями. Ниже я привожу список самых популярных задач, с которыми приходится работать разработчику.
Маршрутизация запросов, построение слоя контроллера.
Написание сложной и ветвистой бизнес логики.
Работа с базами данных.
Работа с транспортом для сообщений.
Тестирование.
Статический анализ кода.
CI/CD.
Маршрутизация запросов / слой контроллера
Задачи, которые входят в этот слой - это направлять каждый http запрос на тот метод, который займется его обработкой. В это также входит описание модели данных, которая передается на вход, а также сериализация запроса и десериализация ответа.
На данный момент самым популярным фреймворком для построения web сервисов является Spring, а именно Spring Boot, который сразу имеет встроенный контейнер сервлетов tomcat, либо netty - в зависимости от того какой набор конфигурации выбран.
Так что для описания эндпоинтов вашего приложения вам практически всегда, в 9 из 10 случаев, придется использовать аннотации @GetMapping и @PostMapping. В том единственном варианте из 10 за маршрутизацию будет отвечать библиотека, которая была написана внутри компании и будет делать то же самое, что и Spring Boot, только “по-своему”.
Раз практически везде используется Spring Boot, то де факто стандартом индустрии для сериализации и десериализации http запросов и ответов является библиотека Jackson. Она также входит в зависимости Spring Boot и активно используется внутри.
Чтобы ее использовать потребуется создать экземпляр ObjectMapper и сконфигурировать его, если будет нужно. Имейте в виду, что в Spring Context уже будет инициализированный экземпляр, настроенный как нужно Spring, так что используйте его осторожно.
Также иногда используют библиотеку от Google - GSON, принципиально она не отличается от Jackson.
Написание сложной и ветвистой бизнес логики.
Выше мы уже выяснили, что стандартом индустрии по разработке web приложений на java является Spring. Это не значит, что вы не сможете встретить условный Javalin или Ktor, так что рассмотрим основную вещь которую очень любят в Spring и так или иначе реализовывают в любом другом фреймворке. Этим подходом является паттерн dependency injection.
Если коротко, то dependency injection это про то, что вы написали отдельный кирпичик кода - класс и используете его в тех местах, где требуется логика этого кирпичика вместо написания новой.
Так что в любом проекте, в котором вы окажетесь будет некий контекст, в котором будут храниться эти кирпичики кода и наличие этого контекста никак не зависит от фреймворка, выбранного для разработки. Скажу по-секрету, что даже один из самых прогрессивных Европейских банков отказался от Spring и разрабатывает веб сервисы на чистой Java, даже у них есть контекст, который в который закладываются все “сервисы” и “компоненты”, использующиеся в бизнес логике приложения.
Работа с базой данных.
Никакое веб приложение не обходится без использования хранилища данных. Таким хранилищем может быть все что угодно - текстовый файл, кэш reddis. Но чаще всего конечно используется база данных, опять же стандартом индустрии сейчас являются:
Postgresql (удобная, производительная, бесплатная).
Oracle (чуть менее удобная, производительная, имеет вендорный формат.
MongoDB (очень удобная для стартовой разработки ввиду нереляционности, крайне распространена в облачных решениях).
Для доступа к базе данных нужно иметь возможность открывать соединения, следить за открытыми потоками, выполнять sql запросы, заниматься конвертацией и тд.
В настоящее время большое распространение имеет подход ORM - Object-Relational Mapping. Чтобы покрыть весь спектр задач для хранения информации бд нужно решать 4 вида операций (тот самый CRUD) - create, read, update, delete.
Самые популярные реализации этого подхода заключает в себе фреймворк - Hibernate. Он способен генерировать sql запросы в зависимости от кода и сущностей, однако делает это не всегда оптимально.
Также мы не забыли, что стандартом индустрии является Spring Boot, для него также существует реализация ORM работы с бд - Spring Data JPA. Она представляет собой обертку над Hibernate , с которой можно работать на более высоком уровне абстракций. Она удобно конфигурится и даже позволяет писать запросы без sql вообще. Но если есть потребность написать raw sql и выполнить его, это также можно сделать.
И наконец самый мощный инструмент, который предоставляет самое лучшее быстродействие, но фактически не реализует ORM идеологию - jdbcTemplate. Его суть в выполнении сырых sql запросов. Но если написать поверх него свою логику конвертации и применять его для хранения сущностей в бд по логике ORM, то получится очень быстрый и кастомизируемый инструмент.
Работа с транспортом
В качестве транспорта для сообщений используют такие синхронные способы как http запросы GET/POST. Для них используется либо RestTemplate, который входит в список зависимостей Spring Boot, либо более новый и WebClient.
Для асинхронных взаимодействий используются брокеры сообщений, самые популярные из которых - rabbitmq и kafka. В этой статье я не буду погружаться в их отличие друг от друга. Остановлюсь на способе интеграции с ними из кода - для этого используются модули Spring Boot, либо самописный “велосипед”, если речь идет про большую компанию. Самые популярные расширения для Spring Boot проекта - это spring-kafka и spring-boot-starter-amqp.
Тестирование
Тестирование - это неотъемлемая часть любой уважающей себя разработки. В наших реалиях если разработка ведется не сразу в TDD парадигме (Test Driven Development), то внутри команды устанавливается порог кода, который должен быть покрыт тестами.
Тесты пишутся в следующих форматах:
unit тесты - для тестирования берется отдельный класс или даже его метод.
интеграционные тесты - тестируется отдельный участок системы вместе с интеграцией с другими элементами. Например интеграционное тестирование процесса в сервисе и его работа с базой данных.
Сторонние библиотеки в тестах нужны для решения задач непосредственно тестирования, а также мокирования (эмуляция ответа какого-то сервиса или интеграции).
Для тестирования чаще всего используют junit 5, TestNG, kotest (kotlin). Для мокирования стандартом java разработки является mockito, для kotlin - mockk. Для тестирования Spring Boot приложений используется стартер spring-boot-starter-test, который уже включает в себя все необходимые зависимости и умеет строить Spring Context для каждого теста.
Крайне редко бывают настолько сложные и витиеватые процессы, что для тестирования одного сценария нужно вызывать много эндпоинтов одного сервиса. В таком случае нужно быть готовым к тому, что вы столкнетесь с самописными “велосипедами” такими как отдельное Spring Boot приложение, которое занимается вызовом эндпоинтов и тестированием основного тестируемого приложения.
Статический анализ
Суть статического анализа кода - это проверка кода на соответствие условиям - отсутствие дублирующего кода, покрытия тестами, соответствие код стайлу и тд.
Как правило для проверок соответствия код стайлу используются такие штуки, как “Линтеры”. По своей природе это те же самые плагины для gradle, maven. Обычно они запускаются автоматически в ходе настроенного пайплайна. Иногда нужно быть готовым, что нужно вызвать команду, которая отформатирует ваш код по настроенным в линтере правилам.
Для Java самыми популярными линтерами являются - Checkstyle и SonarLint. Для kotlin - ktlint
Для статического анализа, с подсказками и прочими полезными штуками в подавляющем большинстве проектов используется настроенный sonarqube. Для маленьких проектов - codacy или codeclimate. Я бы рекомендовал их использовать даже для пет проектов.
Однако не все проекты имеют выстроенные процессы по поддержанию чистоты кода. Это может происходить в силу различных причин - быстро изменяющийся проект, недостаточное количество времени у команды для выстраивания процессов или c
CI/CD - Continuous Integration и Continuous Deployment - это процессы, без которых невозможно представить современную разработку. Можно запаковывать jar файлы руками и руками разворачивать их на серверах, но это увеличивает вероятность ошибок, вызванных человеческим фактором. Чтобы базовые инфраструктурные действия не вызывали большой головной боли, обычно используются скрипты для сборки и деплоя.
Как правило рядовым разработчикам приходится заниматься этим довольно редко, обычно это находится в зоне devops инженеров. Как правило скрипты выполняются в окружении Jenkins, либо Gitlab CI.
Сами скрипты представляют собой набор действий, которые должны быть выполнены для достижения той или иной цели. Самое сложное может быть в том чтобы понять как связывается код внутри приложения и с деплоем. Для этого используются системы сборки. На данный момент для бэкенда существуют две самые популярные - maven и gradle. В 9 случаях из 10 это maven, он довольно грубый, но функциональный и имеет большое количество плагинов. Также изредка встречается gradle, он в свою очередь более свежий, но менее широко распространенный. По функционалу ничем не уступает maven в большинстве моментов.
Вывод.
В этой статье мы рассмотрели основные технические моменты, которые приходится решать бэкенд разработчику в настоящее время. А также основные способы решения задач для каждого из этих технических направлений. Буду рад информации в комментариях о том - с помощью какого инструмента в своем проекте вы решаете задачу и полностью ли вы довольны этим инструментом.
Фото от Tracy Adams на Unsplash
Комментарии (44)
AlexDevFx
06.04.2022 19:36-3Извинте, я тут из мира .NET мимо проходил.
Я Redis не только как кэш использую, но и как хранилище фоновых задач. Ну я читал, что его можно задействовать как Message Queue https://dev.to/lazypro/message-queue-in-redis-38dm.
Наблюдаю с интересом за Kotlin. Смущает то, что он всё же в экосистеме Java, которая постепенно будет сходить на нет на андроиде. Да жалуются, что Java отстает в развитии от других языков. Как вам Kotlin, насколько удобна на нём разработка?
v-aksenov Автор
06.04.2022 20:38-1Redis как кэш - само собой.
Вы вероятно невнимательно прочитали, в статье для транспорта сообщений я писал про rabbitMQ, это совсем другая вещь :)
https://www.rabbitmq.com/
v-aksenov Автор
06.04.2022 21:06+4Что касается сравнения Kotlin и Java для бэкенд разработки. Если коротко, то могу сказать, что java живее всех живых и от нее никто не отказывается и врядли откажется в ближайшее время. Новые версии добавляют фичи, которые делают написание кода более приятным.
Kotlin для бэкенда сильно более приятен, это фактЕсли будет интересно мое чуть более развернутое мнение, то вот моя статья на эту тему: https://tproger.ru/articles/sravnenie-kotlin-i-java-pri-napisanija-backend-prilozhenij/
Бонусом вопрос - насколько я изучал, в .NET мире довольно приятно выглядит синтаксис и работа с библиотеками. Насколько это приятно и удобно на самом деле?
1dNDN
07.04.2022 00:08Максимально удобно и приятно.
Одной командой/кнопкой добавляется nuget пакет и все.
Rider/Resharper все зависимости (в случае, если в соседнем проекте в том же решении есть нужная либа) и директивы using подтягивает по одному нажатию хоткея.
Если либы нет в nuget, то парой кликов добавляется ссылка на dll.
Flaksirus
07.04.2022 00:40+1Как тот кто пришел в жаву после дотнетов, могу сказать что намного приятнее. Во первых система сборки понятная и единая, пакеты тоже максимально понятны. Ну и язык конечно намного более богатый и развитый. Жава жива, да, но скорее вопреки чем благодаря. Фактически это тот же кобол - язык не лучший, но решения поддерживать же кому-то надо. Вот и раздули персонал, а теперь раз персонал у нас умеет только в жаву, будем и новые проекты пилить на этом недоязыке. А персонал он нового ничего не любит и даже противится, вот и останемся на жаве.
Тут вот еще JPA упоминается - так вот ормка в дотнете тоже намного лучше и приятнее. Элементарно сортировка будет `.OrderBy(x -> x.Field)`, а не по рандомной строке как в жаве `Sort.by(ASC, "Field")`.
Nialpe
07.04.2022 08:31+1История из личного опыта... Устраивался на работу в крупный банк и одним из вопросов было "что нового появилось в 8-й версии". Более-менее ответил, т.к. уже давно 11+ использовал, ждал выхода 17-й, поэтому многие возможности языка воспринимал как само собой разумеющиеся. И лишь в первый день работы понял истинный смысл: половина сервисов на 1.7 и переводит выше никто не собирается - "работает? не трогаем."
А так как тикеты и поддержку никто не отменял, то я теперь совершенно точно знаю ответ на вопрос, описанный мною в первом абзаце - это тот локоть, который близок, но не укусишь))) И особенно цинична ситуация, когда в других сервисах вполне себе могу писать код на 11-й.
tuxi
07.04.2022 15:37+1Прилично много энтерпрайз кода на 5 версии еще работает. Кодовую базу в пару десятков миллионов строк перевести одним махом не просто. Плюс, надо понимать, что может потребоваться сначала например с 5й мигрироваться на 7ю (ну может на 8ю) и только потом дальше. Энтерпрайз неохотно подписывается на самые свежие версии.
Как профит, недавняя история с log4j обошла стороной тех, кто на старых версиях 1.х.х сидел.
Gmugra
07.04.2022 21:30+4Это собственно то за что Enterprise ценит Java и не откажется от нее никогда.
Вот свежий личный опыт:
огромная система из 10-ков приложений которая пишется и поддерживается 15+ лет.
Полный набор (все на Java): консольные утилиты, десктоп приложения(огромного размера), JEE в изобилии, Web интерфесы и даже кое что на Spring(версия 3 :) )
Используется огромное количество внешних библиотек(сотни. буквально), некоторые из которых уже не поддерживаются и не развиваются лет 10.Cамые старые куски кода, определенно, писаны еще до Java 5.
Все это работало на Java 7 и сервера: Power и AIX O_o
Переписать это всё с нуля, в соответствии с модными трендами - просто не реально: работа на годы для не маленькой команды. Оценить объем работ невозможно.
Однако, за 4 месяца(причем половина времени потрачено на тестирование) все это мигрировали на Java 11, Intel + RedHat и новый Application server. Силами 2-х людей.
Менять код почти не пришлось(было несколько случаев связанных с необходимостью обновить некоторые библиотеки, там где выбора другого не было)
И все работает.
Я честно сам не очень верил в успех, особенно в отношении десктоп приложений(в коде AД и пепел), но... работает.
tuxi
07.04.2022 22:36+1Проделывал аналогичное на проекте корнями уходящим в 2003 год, с 1,4 версии на 6-ю, потом на 7-ю версию. А уже на 8-ю переехали практически сразу. Работоспособность полная. Рефакторинг можно делать не торопясь.
Nialpe
08.04.2022 08:28+1Отличный кейс. Я не всегда понимаю, почему зачастую переход на более новую версию отождествляют с переписыванием с нуля. Не с нуля. Да муторно, да убедить бизнес в ценности того, что специалисты тратят время, а "снаружи ничего вроде как и не изменилось" трудно, но глаза боятся, а руки делают.
Возможно такая работа (перевод на новую версию) на любителя (не в смысле навыков), ведь многие любят новые проекты на новых-модных-молодежных и уж там-то они покажу во всей красе, что такое идеальный код и архитектура. А я вот из когорты людей, которые нравится усовершенствовать имеющийся. Душа радуется, когда исправляешь ошибки, улучшаешь производительность по времени или ресурсам или изящно убираешь копипасты.
muzuro
07.04.2022 09:08По поводу kotlin для бекенда. Как вы его используете для jpa сущностей? Я лично устал страдать от того что не удается все not null поля объявлять not nullable в классе сущностей.
v-aksenov Автор
07.04.2022 17:28Да, котлин для jpa сущностей это полное несоответствие реализации jpa и логики котлина. Мы используем jdbcTemplate с самописными конверторами и аннотациями для маппинга в sql и обратно. На каждый чих приходится писать sql, зато все максимально прозрачно.
А для пет проектов да, забавляюсь с nullable полями со значениями по умолчанию. Пока не нашел чего-то проще и лучше
Gmugra
07.04.2022 21:51Kotlin для бекенда идея крайне спорная и я бы сказал умирающая.
Лично сталкивался с тремя проектами за последние годы. Все успешно справились. Но. Два из трех прожект менеджеров сказали мне в кулуарах: больше никогда.
Проблема собственно конечно не в языке. А в экосистеме вокруг.
И учитывая что разрыв между Java и Кotlin сокращается все больше... (Java таки уже умеет в lambda, и в текстовые блоки :), да и Loom уже не за горами) то и смысла все меньше.
IMHO: если бы не Google был бы Kotlin примерно там же где Groovy. При всех, бесспорных, достоинствах.
siziyman
08.04.2022 11:56Kotlin для бекенда идея крайне спорная и я бы сказал умирающая.
Глупость какая-то.
Два из трех прожект менеджеров сказали мне в кулуарах: больше никогда.
Я могу найти людей, которые и про джаву скажут то же самое, и вообще про любой другой язык. Проблема или в ПМах, или в команде, или в подходах, редко в инструментах. :)
Хотя я не знаю, насколько некомпетентен или архаичен должен быть джавист, чтобы через неделю не мочь выдать на котлине продакшн-реди код.
Проблема собственно конечно не в языке. А в экосистеме вокруг.
Экосистема - вообще вся джавовая, плюс "локальные" ориентированные под котлин навороты. При этом в успех джавы вы вроде как верите, а ничего не мешает все те же инструменты использовать в котлине.
разрыв между Java и Кotlin сокращается все больше
Некоторые вещи, от которых в джаве больно, к сожалению, никогда не исчезнут, потому что джава печётся об обратной совместимости (и это круто), а местами многословность синтаксиса и ограниченность имеющих АПИ делают прям некомфортно.
java таки уже умеет в lambda
JEP на лямбды появился в том же году, что и первый релиз котлина: 2011. Уж поверьте, не в лямбдах дело.
И я даже не то чтобы большой фанат Котлина - ну, неплохой язык, не более - но говорить, что он "умирающий" на бэкэнде как-то очень странно.
Gmugra
08.04.2022 14:38Это, конечно, мой субъективный опыт. Но чтобы вы понимали бэкграунд: я работаю на очень большой, европейской, галере: тысячи разработчиков и сотни проектов во всех сферах бизнеса.
Я сталкиваюсь прямо или косвенно со множеством проектов каждый год и я не вижу Kotlin в бэке практически совсем. Андроид разработка - да. там оно уже доминирует (хотя и на Java там проекты есть до сих пор, и не сказать что это редкость)А бэкенд это Java и C# в подавляющем большинстве случаев.
Причем, по моим ощущениям, именно С# потихоньку откусывает у Java. Но не Kotlin.siziyman
08.04.2022 15:34Но чтобы вы понимали бэкграунд: я работаю на очень большой, европейской, галере: тысячи разработчиков и сотни проектов во всех сферах бизнеса.
Ну, одна галера, ну, бывает. Я в галере с тысячами разработчиков тоже работал. :)
Я вообще галеры не люблю, если честно, и это в моих глазах скорее минус, чем плюс, почти всегда в продуктовой разработке можно настроить процессы и выбрать инструменты лучше.
Причем, по моим ощущениям, именно С# потихоньку откусывает у Java
С одного на другое редко именно проекты крайне редко переходят, по ощущениям, потому что это замена шила на мыло без значимого профита. По этой же причине разрабы туда-сюда относительно свободно мигрируют.
aleksandy
06.04.2022 21:08+4также существует реализация ORM работы с бд -
Spring Data JPA. Она работает быстрее, конфигурируется удобнее, чем hibernateКакая ересь. Spring Data JPA - это ни что иное, как обёртка над JPA-провайдером, коим является Hibernate, т.е. она тупо не будет работать без настроенных Hibernate/EclipseLink/OpenJPA.
v-aksenov Автор
06.04.2022 21:11-3Согласен, можно сформулировать иначе. Более правильно будет сказать, что Spring Data JPA - следующий уровень абстракции над hibernate и более удобная в конфигурации обертка.
siziyman
06.04.2022 21:22+7Нет, это не "можно сформулировать иначе", это фактическая ошибка и следующие за ней не менее ошибочные выводы про скорость.
siziyman
06.04.2022 21:10+8Много вопросов к статье, если честно, даже не считая того, что это какой-то поверхностный обзор, который может и SEO написать и залить на главную какого-нибудь там джавараша или скиллбокса (и теги на это же намекают, если честно).
Если коротко, то dependency injection это про то, что вы написали отдельный кирпичик кода - класс и используете его в тех местах, где требуется логика этого кирпичика вместо написания новой.
Такое описание DI вызвало некоторую боль, если честно.
Также мы не забыли, что стандартом индустрии является Spring Boot, для него также существует реализация ORM работы с бд -
Spring Data JPA. Она работает быстрее, конфигурируется удобнее, чем hibernate и даже позволяет писать запросы без sql вообще.Spring Data JPA - всего лишь обёртка (плюс пачка адаптеров) над непосредственно библиотеками/фреймворками для работы с БД, и чаще всего под капотом у неё - да, вы угадали, Hibernate. Расскажете, как обёртка над Hibernate будет работать быстрее, чем Hibernate? :)
Ну то есть как перечисление терминов с их неглубоким объяснением + чеклист полезных для ознакомления инструментов статья работает сносно, а как что-то большее её рассматривать - вредно.
iliabvf
06.04.2022 23:40+2Скажите, а если мне не нравится Hibernate, люблю простой JDBC, что тогда делать?
oxff
07.04.2022 00:32+4Для этого есть весьма гибкий JdbcTemplate, который интегрирован со спринговым менеджером транзакций.
Ну и JPA тоже прекрасно поддерживает нативный SQL и хранимые процедуры, и можно поекрасно обойтись без ORM.
aleksandy
07.04.2022 01:17За первый абзац - плюс, а вот второй - очередная ересь. Для чего заморачиваться с настройкой JPA, чтобы потом пользоваться исключительно нативными запросами? Чтобы что?
JdbcTemplate - хорошее решение, если спринг всё равно используется.
Хотя нет ничего сложного в том, чтобы написать простейший UnitOfWork на 2 метода (один просто что-то делает, второй - возвращает какой-то результат), принимающих лямбды с полезной работой. В них реализовать работу с транзакцией. И пользоваться им, работая с jdbc напрямую. Через некоторое время это всё выльется в какое-то подобие JdbcTemplate-а, но попроще, сугубо под решаемые задачи.
oxff
07.04.2022 06:00+2В простых приложениях на Spring Boot типа микросервисов, с единственным дата-сорсом и одним менеджером транзакций, модуль "Spring Data JPA" фактически не требует вообще никакой настройки. В более сложных случаях это тоже делается довольно просто, всего-то несколько бинов объявить в конфиге и добавить квалифаеры для контроля транзакций.
Да, JPA/Hibernate при неумелом обращении может принести много вреда. Я неоднократно видел проекты которые буквально загибались под нагрузкой из-за этого. Причём, как правило, проблема была в том что тимлид говорил "а вдруг придётся переходить на другую СУБД?", и потому отказывался от native SQL.
Но если понимать что происходит под капотом, то есть и плюсы. Лично я сторонник строгих нативных запросов (и никакого JPQL) с чётко предсказуемыми эффективными планами и индексами, а также функций/процедур СУБД в чуть более сложных случаях, или если размер запроса превышает некоторый порог. Потому что негоже мешать в кучу SQL и Java. К тому же как DBA я всегда могу оптимизнуть соранённый запрос прямо внутри СУБД без редеплоя апликухи и лишней бюрократии.
Но для простейших вещей типа
findByName()илиexistsByProductId()можно спокойно положиться на способность JpaRepository генерировать код автоматически по названию метода в интерфейсе. Это позволяет избавиться от бойлерплейта и это здорово. Ещё мне нравится объявлять отдельные@Repositoryдля разных классов объектов, тем самым чётко разделяя их по зонам ответственности.Если же вам совершенно ненавистен Hibernate (понимаю!) то есть "Spring Data JDBC". Это очень крутая штука, если вы ещё не успели познакомиться. Это почти такие же CrudRepository как в JPA только очень лёгкие, на чистом JDBC, но правда с небольшими ограничениями. Разработка команды Спринга. И там точно так же можно декларативно объявлять простые методы без написания кода.
К сожалению, автор этого поста об этом замечательном модуле даже не упомянул.
IoannGolovko
07.04.2022 22:20Все так. Интересно посмотреть, как одними только средствами jpa будут доставать записи по внутренним полям jsonb
oxff
07.04.2022 23:22+1С точки зрения JDBC (а всё в конечном счёте сводится к нему), тип
jsonbмапируется наjava.sql.Types.OTHERи прилетает на клиента как строка. Вы можете либо получить эту строку целиком и превратить в Java объект самостоятельно, либо выбрать нужные атрибуты в native SQL запросе и вернуть их в отдельных полях кортежа. Решайте сами что вам удобнее в вашем конуретном случае.Для первого варианта в JPA есть поддержка кастомных типов данных. Можете сами имплементировать интерфейс
org.hibernate.usertype.UserType. Есть готовая библиотека от Vlad Mihalcea которая поддерживает всевозможные типы. Вот тут почитайте к примеру: https://vladmihalcea.com/how-to-map-json-objects-using-generic-hibernate-types/
Кстати таким же образом происходит мапированиеenumтипов Postgres и Java.IoannGolovko
07.04.2022 23:57+1Пост выше был в поддержку второго абзаца. Это как пример того, что без нативных запросов можно наворотить гораздо большее зло.
oxff
08.04.2022 00:31+1Это точно! Плюсую.
Но всё таки использование одинаковых enum типов в Java и в Postgres это супер фича, которая повышает чисту и безопасность кода, и уберегает от ошибок.
siziyman
07.04.2022 01:23+3Нет в этом ничего плохого, без хибера, по моему скромному мнению, вообще живётся лучше, чем с ним. Но то, конечно, мнение. :)
Я бы предложил ещё посмотреть на такие инструменты, как querydsl, jooq, jdbi - авось приглянутся.
Gmugra
07.04.2022 14:43+1Я тоже не люблю ORM в любых проявления и, поверьте, таких как я МНОГО. Поэтому есть как минимум две популярных и активных альтернативы: http://jdbi.org и https://www.jooq.org. Посмотрите. Попробуйте. И то и другое прекрасно применимо в проектах любых размеров, кто бы чтобы там не говорил.
tuxi
07.04.2022 15:41Радоваться и развиваться в направлении увеличения производительности :-) Быть в курсе последних версий пулов коннектов и самому прогнать их через жесткие стресс тесты, чтобы понимать их возможности.
Ниша для таких решений на рынке точно есть, мало кто может показать скиллы оптимизации на таком "низком" уровне.
panzerfaust
07.04.2022 07:33Суть статического анализа кода - это проверка кода на соответствие
условиям - отсутствие дублирующего кода, покрытия тестами, соответствие
код стайлу и тд.Суть статического анализа кода - в проверке кода без его исполнения. По определению. Что является предметом проверки - вопрос вторичный. У вас перечислены одни линтеры, но есть еще направление SAST, представленное продуктами вроде Checkmarx, Solar AppScreener, Fortify
anaken
07.04.2022 11:04+2Я за последние 5 лет работал в 3х разных крупных компаниях (2 из них топ банки), и даже в них не встречал широкого использования SAST.
Автор не упомянул еще много чего, но как вы можете наблюдать из заголовка и текста статьи - целью было не описание всего, что есть, а ознакомление с часто используемыми инструментами в Java-проектах.
IoannGolovko
08.04.2022 00:00Процессы до этого не успевали дорасти. Сейчас уже активно используется в одном из топ.
Volakrab
07.04.2022 07:49+2MongoDB (очень удобная для стартовой разработки ввиду нереляционности
Тут что-то смешалось теплое с мягким, не?
vashu1
07.04.2022 18:15+2Как большинство Java проектов выглядят изнутри
Разница между статьей и реальностью примерно как между школьным описанием размножения и тяжелой порнухой.
"У нас тут используется такая версия джавы, а тут такая, а тут вообще шестая. Часть мейвеновских пакетов грузятся с корпоративной репы, там подписи поломались, так что проверку отключаем. И вообще проверку ssl отключаем - система безопасности все перехватывает. Тут вся функциональность сделана на мэйвеновских плагинах, как работает эта магия никто не знает. Эти тесты полгода назад поломались, не обращай внимания."
alexdoublesmile
07.04.2022 21:47хорошая статья, только про секьюрность и spring ws ничего не написал - это огромный пласт иных задач в современной java
Jamon
07.04.2022 22:33Добавлю от себя что мне понравилось для работы с БД - так это MyBatis, очень здорово sql запросы мапить через xml конфигурацию.
GaDzik
Спасибо. Оч полезно.