Промышленные технологии то же бывают неудачными. Тут чистая психология, а не реальные аргументы. Слава богу в эпоху AI психологию можно не учитывать. AI удобнее писать напрямую SQL без магии. На это тратится меньше токенов.
Технически безграмотная статья. Пример "Поскольку схема очень сложна и нам нужно поддерживать множество способов доступа к её данным, требуются ленивая загрузка, каскадирование, графы загрузки и множество других паттернов и возможностей. Следовательно, необходим очень функциональный слой персистентности. Именно поэтому Hibernate и JPA были важны ..." тут поменяны местами причина и следствие. ленивая загрузка, каскадирование, графы загрузки и пр.. требуются для Hibernate и JPA, но никак не наоборот! Для работы с базой нужен только SQL и ничего более. С SQL все на порядок проще. Нужно просто его выучить на продвинутом уровне. Spring JDBC — это не тот механизм, который стоит использовать, он действительно не удачный. Но Hibernate это неудача в квадрате, что в монолите, что в микросервисе. В статье смешено несколько подходов микросервисы и монолиты, Hibernate vs SQL. Это нужно рассматривать изолировано, что не было каши.
К сожалению, такой подход мало продуктивен. Для меня самое лучшее — это способность AI быстро, что-то написать. Исчезает эффект белого листа. Да вещь чисто психологическая, но мне очень нужная. Так же удобно проектировать архитектуру для backend.
Решение сложное. Но расстраивает, что опять пишут велосипед. Нужно нанять архитектора и он за месяц выдаст принципиальное решение. Реализовывать которое небольшие полу года!
Жесть. SQL самый простой и ужасный язык. За 30 лет он слабо изменился. Но все время его хотят улучшить. Так придумали orm. Теперь надо знать orm и sql. Некоторые стали считать, что sql, не надо знать. Ребята выучитье sql и не придется ничего изобретать.
XML просто разметка начала и конца sql. Занимает две строчки, но аргумент принимается. Можно сделать лучше, хотя особо не мешает.
Очень интересно, что не понравилось. Я применял её 8 лет, в начале немного неправильно. После устранения авто генерации, не было ни одной проблемы.
Промышленные технологии то же бывают неудачными. Тут чистая психология, а не реальные аргументы. Слава богу в эпоху AI психологию можно не учитывать. AI удобнее писать напрямую SQL без магии. На это тратится меньше токенов.
MyBatis, вариант размещением SQL в XML.
Технически безграмотная статья. Пример "Поскольку схема очень сложна и нам нужно поддерживать множество способов доступа к её данным, требуются ленивая загрузка, каскадирование, графы загрузки и множество других паттернов и возможностей. Следовательно, необходим очень функциональный слой персистентности. Именно поэтому Hibernate и JPA были важны ..." тут поменяны местами причина и следствие. ленивая загрузка, каскадирование, графы загрузки и пр.. требуются для Hibernate и JPA, но никак не наоборот! Для работы с базой нужен только SQL и ничего более. С SQL все на порядок проще. Нужно просто его выучить на продвинутом уровне. Spring JDBC — это не тот механизм, который стоит использовать, он действительно не удачный. Но Hibernate это неудача в квадрате, что в монолите, что в микросервисе. В статье смешено несколько подходов микросервисы и монолиты, Hibernate vs SQL. Это нужно рассматривать изолировано, что не было каши.
Где тут проблемы разработки, не понял.
К сожалению, такой подход мало продуктивен. Для меня самое лучшее — это способность AI быстро, что-то написать. Исчезает эффект белого листа. Да вещь чисто психологическая, но мне очень нужная. Так же удобно проектировать архитектуру для backend.
Обновления можно и нужно заменить insert с новой версией записи.
Вы реализовали маленькую часть MyBatis из java мира
Решение сложное. Но расстраивает, что опять пишут велосипед. Нужно нанять архитектора и он за месяц выдаст принципиальное решение. Реализовывать которое небольшие полу года!
Жесть. SQL самый простой и ужасный язык. За 30 лет он слабо изменился. Но все время его хотят улучшить. Так придумали orm. Теперь надо знать orm и sql. Некоторые стали считать, что sql, не надо знать. Ребята выучитье sql и не придется ничего изобретать.