ฝัง
- เผยแพร่เมื่อ 15 ก.ย. 2024
- Не во всех случаях стоит использовать ORM. Если вам нужен полный контроль или вы используете простые сущности, то возможно вам стоит присмотреться к Spring Jdbc.
Подготовил в этом видео материал с минимальным количеством кода и всяких настроек, которыми кишат остальные видеоуроки.
Раскрываю, почему лучше использовать NamedParameterJdbcTemplate, а не JdbcTemplate.
Код здесь:
github.com/dis...
Прекрасный пример, всё коротко и по сути!!! Спасибо автору👍👍👍
Огромное спасибо за такое видео!
Очень долго приходилось гуглить, чтобы разобратьс, как с этим работать. А тут за 20 минут всё коротко и понятно
Спасибо) шикарное видео. Все очень зашло. Жду новых видео по Java
Отлично зашло. Подача материала очень хороша. Так держать!
Хорошее сравнение. Спасибо.
Спасибо большое за это видео!
Мне сильно помогло, хоть и большинство деталей здесь опущено, благо хватило багажа понимания.
Особенно выручил момент с фиксированным временем, именно это мне и нужно было. Боюсь представить сколько бы я гуглил, не зная что именно гуглить )) а тут на тебе, да еще и с примерами.
Молодец.Круто все показал!
Немного хочу добавить
В общем с помощью JDBCTemplate тоже можно работать с не простыми сущностями, да и ORM тоже имеет довольно неплохой контроль. Я думаю что ORM работает медленнее и, в общем, это сильно влияет при хайлоаде и, бывает так, что с помощью ORM ты достаешь лишние данные, а с JDBCTemplate ты можешь это контролить.
Еще есть более удобный способ задать параметр через Map.of(). правда максимум можно передать до 10 параметров
Существует только два случая, когда в проектах не используют полноценный ORM (суть JPA, а в идеале ещё и прекрасный Spring Data).
Первый, это когда схема базы не соответствует объектной модели, то есть 1 запись в таблице не отображает объект доменной модели (бизнес-сущность). Такое бывает, например, в случае хранения в БД каких-то отчётов, показаний счётчиков и прочая, где нужны только SELECT выборки и инкрементирование счётчиков. Но не обычные операции CRUD + управление связями (агрегациями) хранящихся объектов.
Второй же случай, это когда разработчики и архитекторы не владеют в полной мере JPA и считают, что он лишает их какого-то там контроля, который у них якобы есть при работе с JDBC. Всё, что они получают вместе с JDBC это лапшу boilerplate кода, в которым они изобретая велосипеды пытаются решать все те проблемы не соответствия объектной и реляционной модели, которые решает за разработчиков JPA. Ну, а сдуру, можно, как известно, много чего сломать. В том числе и наляпать всяких там n+1 проблематик и тп.
Однако, если изучить возможности JPA (чаще всего это Hibernate), то вы поймёте, что это средство, которое выполняет за вас 80% рутинных операций (SQL запросов), которые выполняются крайне редко и не влияют на производительность и оставляет возможность вручную затюнить те 20%, которые в основном выполняются и на производительность влияют. Затюнить можно как через аннотации сущностей, так и использование HQL или даже того же нативного SQL, там, где без этого не обойтись и только там. И сэкономить огромное время тем самым, а так же не мусорить код своими велосипедами.
Привет. Можешь запилить видео с примером Spring Boot + Kafka? На каком то приближенном к реальности примере(только не так, как обычно делают тупо producer-consumer и вывод в консоль).
Привет. Запилю.
@@javistt ждемс)
эм... а что делать если мне нужен не только public Customer getCustomer(), но также и метод с возвращаемым типом в виде коллекции public List getCustomers()?
public List getCustomers() {
String sql = "SELECT * FROM customer";
return template.query(sql, new CustomerRowMapper());
}
@@javistt благодарю за ответ. :D
С удовольствием посмотрел. Единственное было интересней на Kotlin смотреть, Java очень вербозная.
Лол. Попробуй это переписать на котлин, выигрыше будет минимальный, а читабельность отвратительная
песня