Добрый день. Попробовал Hibernate и MyBatis
MyBatis позволяет писать свои SQL запросы. В тоже время если использовать Spring Data and Query, то можно писать native queries или JPQL с Hibernate

Здравствуйте, Aleksei_Lekomtsev, Вы писали:

A_L>Добрый день. Попробовал Hibernate и MyBatis
A_L>MyBatis позволяет писать свои SQL запросы. В тоже время если использовать Spring Data and Query, то можно писать native queries или JPQL с Hibernate

MyBatis почти ничего не дает в плане INSERT/UPDATE/DELETE. Все придется писать вручную. Только SELECT он умеет маппить на классы
Кроме того, в нем нет механизма отслеживания изменений в классе или в коллекции. Если сделал изменения — выполни сохранение/изменение сам.

Это его недостатки и в то же время достоинства. Ты будешь писать SQL сам и можешь сделать это эффективно.

В Hibernate обычно сами SQL не пишут, поручают фреймворку. Так что SQL не всегда будет наиболее эффективным. Можно, конечно, перейти на нативные запросы или JPQL, да, но это будет его использование "не как принято", и обычно без особых причин это не делают.

Здравствуйте, Aleksei_Lekomtsev, Вы писали:

Никогда

Здравствуйте, Aleksei_Lekomtsev, Вы писали:

A_L>MyBatis позволяет писать свои SQL запросы.

Позволяет — это если бы была альтернатива. С MyBatis нужно писать свои SQL запросы.

A_L>В тоже время если использовать Spring Data and Query, то можно писать native queries или JPQL с Hibernate

Народ пишет, что Hibernate медленнее и нужно долго сложно настраивать и подкручивать, чтобы приблизиться по скорости.
MyBatis — это некие примочки над JDBC и особо ничего лишнего вроде не добавляет, т.е. по логике действительно должен быть достаточно быстрым.
Я не проверял и не так, чтобы усиленно в целом в Java мире находился.
Сверху спустили мне MyBatis и пришлось немного поработать.
Мне в нём удобно то, что SQL-запросы выносятся отдельно в xml файлики.
Spring Data вроде только атрибуты типа @Query умеет или в java-коде.
MyBatis тоже атрибуты умеет, но по-моему это неудобно.
Что мне относительно удобно было в MyBatis — это компоновка SQL-запроса.
В примерах везде константы иду типа:
@Query("update person set first_name = :firstName, last_name = :lastName where id = :id")
Мне было нужно апдейтить только то, что заполнено, т.е. не null.
В MyBatis это вылилось во что-то вроде:

<update id="updatePerson">
  update person
  <set>
    <if test="firstName">first_name = #{firstName}</if>
    <if test="lastName">last_name = #{lastName}</if>
  </set>
  where id = #{id}
</update>

Если я не ошибаюсь, то в Spring Data и Hibernate подобное решается не очень изящно и нужно городить какие-то новые классы и сбоку прикручивать.
Простым атрибутом там не отделаться.
Я не понимаю почему они нормальный синтаксис не сделали, банально массив для запроса с IN прибиндить нельзя и приходится цикл <foreach> писать в xml.
На голом JDBC больно сидеть, MyBatis всё же поудобнее.
Если устраивает то, что генерирует Hibernate и нет массы сложных запросов, которые выпадают из общего кода, то и не понятно зачем самому с MyBatis типовые CRUD писать.
Если нужно или хочется самому sql весь прописывать, то в принципе жить с MyBatis можно, но как-то всё криво и неудобно по-моему в итоге.

On Feb 19, 2024, 2:07 PM, Aleksei_Lekomtsev <114506@users.rsdn.org> wrote:

AL>Добрый день. Попробовал Hibernate и MyBatis
AL>MyBatis позволяет писать свои SQL запросы. В тоже время если использовать Spring Data and Query, то можно писать native queries или JPQL с Hibernate

MyBatis имеет только два «преимущества»:

1. Позволяет возвращать множественные ResultSet (Hibernate этого не может делать) — я в курсе что это плохая практика, но к сожалению она не искореняема;
   
2. MyBatis позволяет делать модели вокруг ResultSet (то есть намного ниже уровень чем Hibernate/ORM), в hibernate придется описывать такие гибридные модели, иногда это не просто (например в случае с отсутствием ключей в них, либо с вычисляемыми ключами через SP). Таким образом если корпоративная логика приложения написана на основе множества SP (Stored Procedures), то написать код аналогичный «относительно простенькому» в MyBatis на Hibernate под силу скилловому программисту (обычно только ведущие инженеры).

Я предпочитаю Hibernate, только по одной причине — мне он больше нравится. Мне нравится комьюнити, зрелость библиотеки, поддержка его, (моя в том числе) база знаний, он лучше интегрируется с Spring/Java EE.

Когда использовать MyBatis?

• Когда у тебя в команде все знают его, но к сожалению это большая редкость, в основном знают как раз Hibernate;
  
• Когда есть куча legacy-кода, уже написанного на MyBatis (например для использования гибридных моделей на основе тех же SP) — внедрять в такие проекты Hibernate можно только через полную замену слоя MyBatis;

IMHO, найти проблему в MyBatis гораздо сложнее, чем туже в Hibernate. Все эти не очевидные mappers, каждый слой в виде XML/моделей/секций трансформаций и биндинга — она иногда сводит с ума. И в больших продуктах (>100К CLOC) это ведет к большой неразберихи. Hibernate в этом плане проще.

Здравствуйте, r0nd, Вы писали:

R>IMHO, найти проблему в MyBatis гораздо сложнее, чем туже в Hibernate. Все эти не очевидные mappers, каждый слой в виде XML/моделей/секций трансформаций и биндинга — она иногда сводит с ума. И в больших продуктах (>100К CLOC) это ведет к большой неразберихи. Hibernate в этом плане проще.

По-моему наоборот. В MyBatis сам запросы пишешь, никаких отслеживания состояний объектов и т.п. Hibernate под капотом куда больше магии делает.
MyBatis же скажет какой xml упал на какой строке или откуда куда конвертация не сработала в каком запросе.
Некоторые вещи удивляют, костылями приходится что-то решать, но именно локализация проблемы в MyBatis достаточно просто делается.

Здравствуйте, Aleksei_Lekomtsev, Вы писали:

A_L>MyBatis позволяет писать свои SQL запросы. В тоже время если использовать Spring Data and Query, то можно писать native queries или JPQL с Hibernate

Я бы сказал, что MyBatis окончательно и бесповоротно устарел. Программирование в XML давно признано плохой практикой, а сделать селект с prepared statement с преобразованием в объект несложно через spring data или аналогичный самописный враппер:

List<MyModel> results = conn.query("select id, a, b, c from MyTable where id=:id and a=:a")
.set("id", id)
.set("a", a)
.list()
.map(this::toModel)

Здравствуйте, karbofos42, Вы писали:

k> <if test="firstName">first_name = #{firstName}</if>
Жуть, программирование на XML.
Я давно с базами не общался, но в своё время querydsl приглянулся больше всего. Смотрели?

Здравствуйте, karbofos42, Вы писали:

K>В MyBatis это вылилось во что-то вроде:
K>

K><update id="updatePerson">
K>  update person
K>  <set>
K>    <if test="firstName">first_name = #{firstName}</if>
K>    <if test="lastName">last_name = #{lastName}</if>
K>  </set>
K>  where id = #{id}
K></update>
K>

где мои 20 лет
вы еще спринг через xml попробуйте

Здравствуйте, Aleksei_Lekomtsev, Вы писали:

A_L>MyBatis позволяет писать свои SQL запросы.
Может jOOQ а?

Здравствуйте, scf, Вы писали:

scf>List<MyModel> results = conn.query("select id, a, b, c from MyTable where id=:id and a=:a")
scf> .set("id", id)
scf> .set("a", a)
scf> .list()
scf> .map(this::toModel)

С MyBatis будет в интерфейсе маппера объявлен метод вида:

List<MyModel> getItems(long id, String a);

и сам запрос в xml:

<select id="getItems">
  select id, a, b, c from MyTable where id=#{id} and a=#{a}
</select>

Можно и без выноса в xml, в маппере аттрибут навесить:

@Select("select id, a, b, c from MyTable where id=#{id} and a=#{a}")
List<MyModel> getItems(long id, String a);

Не вижу тут никаких проблем с MyBatis в плане синтаксиса и xml

Здравствуйте, ·, Вы писали:

·>Жуть, программирование на XML.
·>Я давно с базами не общался, но в своё время querydsl приглянулся больше всего. Смотрели?

Ну, MyBatis не был моим выбором и не скажу, что в восторге.
Удивило, что в Java среди популярных библиотек вот такие поделки со странными решениями и проблемами.
QueryDSL и подобное видел, но не могу сказать, что и такой подход нравится.
И SQL писать не люблю и при переименовании колонок везде лазить по запросам их переименовывать — сомнительное удовольствие.
С другой стороны можно спокойно SQL в соответствующих инструментах писать, отлаживать и потом вставить в этот XML,
поправив передачу параметров и добавив какие-то xml конструкции, если нужно какие-то проверки и обработки добавить.
Это всё же разные подходы и кому что нравится.

Здравствуйте, GarryIV, Вы писали:

GIV>где мои 20 лет
GIV>вы еще спринг через xml попробуйте

Я тут Helm с его Go template пробую.
Не сказал бы, что далеко от xml ушло, но конечно угловые скобки — это древний отстой, а фигурные скобки — стильно, модно, молодёжно.
Не знаю уж почему выстреливают какие-то сомнительные по удобству инструменты.

Здравствуйте, karbofos42, Вы писали:

GIV>>вы еще спринг через xml попробуйте
K>Я тут Helm с его Go template пробую.

Хрен редьки не слаще. Я за Infrastructure as code (IaC) есличо в том виде как он сделан в AWS CDK например.
Но это епархия девопсов, там свои так сказать "наработки".

Здравствуйте, karbofos42, Вы писали:

K>@Select("select id, a, b, c from MyTable where id=#{id} and a=#{a}")
запросы в строчке (константной). Удобно, безопасно, современно.
Но да уже не 20 а 15 летней давности подход.

ЗЫЖ Есть же jOOQ, нормальный Java/Kotlin код, типобезопасно, компайл тайм проверки и тд. В апдейты умеет, в r2dbc.

Здравствуйте, GarryIV, Вы писали:

GIV>запросы в строчке (константной). Удобно, безопасно, современно.

Неудобно и не безопасно, а когда запросы сложные и объёмные, то и вовсе Mapper'ы превратятся в кашу.

GIV>ЗЫЖ Есть же jOOQ, нормальный Java/Kotlin код, типобезопасно, компайл тайм проверки и тд. В апдейты умеет, в r2dbc.

Jooq не пробовал, типобезопасность и проверки — это хорошо, но синтаксис у него сомнителен в плане удобства и в итоге пишешь тот же SQL не на языке SQL.
Если какой-то сложный запрос, то нужно сначала его писать на SQL, отлаживать, а потом транслировать его в jooq.
Те примеры, что я видел на jooq — не сказал бы, что было приятно читать запросы. Даже SQL приятнее как-то.
LINQ в .NET выглядит куда лучше.

Здравствуйте, karbofos42, Вы писали:

K>Те примеры, что я видел на jooq — не сказал бы, что было приятно читать запросы. Даже SQL приятнее как-то.
Убераргумент, ну неприятно так неприятно.

K>LINQ в .NET выглядит куда лучше.
Linq то выглядит норм (не использовал) но у нас про жабу.

Здравствуйте, karbofos42, Вы писали:

K>·>Жуть, программирование на XML.
K>·>Я давно с базами не общался, но в своё время querydsl приглянулся больше всего. Смотрели?
K>Ну, MyBatis не был моим выбором и не скажу, что в восторге.
K>Удивило, что в Java среди популярных библиотек вот такие поделки со странными решениями и проблемами.
Ну это просто легаси из проектов ~прошлого века. В java много такого, старинные кодовые базы .

K>QueryDSL и подобное видел, но не могу сказать, что и такой подход нравится.
Пишешь код не на кривом SQL, а обычный java-код с компайл-тайм проверками, автодополнением и т.п.

K>И SQL писать не люблю и при переименовании колонок везде лазить по запросам их переименовывать — сомнительное удовольствие.
Так в этом и суть, что у тебя java-код, где работают авто-рефакторинги.

K>С другой стороны можно спокойно SQL в соответствующих инструментах писать, отлаживать и потом вставить в этот XML,
В топку "соответствующие инструменты" и отладка. Пишешь java-код с тестами, а не простыни XML.

Здравствуйте, ·, Вы писали:

·>Пишешь код не на кривом SQL, а обычный java-код с компайл-тайм проверками, автодополнением и т.п.

Вместо кривого SQL пишешь на кривом Java, который старается повторять этот самый SQL.
В итоге пишешь на чём-то промежуточном. Знаешь как что-то сделать на Java, но нужно это как-то иначе записать, как принято в этой библиотеке, чтобы она смогла запись транслировать в SQL.
Либо наоборот знаешь как на SQL сделать, но нужно разбираться как сделать на этой обёртке.

·>В топку "соответствующие инструменты" и отладка. Пишешь java-код с тестами, а не простыни XML.

Так не получится. Всё равно нужно следить за генерируемыми запросами, анализировать как они исполняются в СУБД, какие индексы используются или нужны и т.д. и т.п.
Чисто на Java сидеть и делать вид, что нет СУБД со своим специфическим SQL не получится.
Рано или поздно придётся начать следить за всем этим добром и подкручивать.

Здравствуйте, karbofos42, Вы писали:

k> ·>Пишешь код не на кривом SQL, а обычный java-код с компайл-тайм проверками, автодополнением и т.п.
k> Вместо кривого SQL пишешь на кривом Java, который старается повторять этот самый SQL.
Цель — компилируемый высокоурвневый яп, со строгой типизацией, автодополнением, етс.
Ещё, SQL — очень плохо композится. Т.е. какой-то динамический запрос в sql собираемый из кусочков — жуть, нужен билдер запросов.

k> В итоге пишешь на чём-то промежуточном. Знаешь как что-то сделать на Java, но нужно это как-то иначе записать, как принято в этой библиотеке, чтобы она смогла запись транслировать в SQL.
k> Либо наоборот знаешь как на SQL сделать, но нужно разбираться как сделать на этой обёртке.
Пиши сразу на Java.

k> ·>В топку "соответствующие инструменты" и отладка. Пишешь java-код с тестами, а не простыни XML.
k> Так не получится. Всё равно нужно следить за генерируемыми запросами, анализировать как они исполняются в СУБД, какие индексы используются или нужны и т.д. и т.п.
k> Чисто на Java сидеть и делать вид, что нет СУБД со своим специфическим SQL не получится.
k> Рано или поздно придётся начать следить за всем этим добром и подкручивать.
Ну это уже отладка и оптимизация. Ровно так же приходится смотреть на байткод, машкоды, етс. Но это не повод писать с ассемблерными вставками.