Комментарии 23
Вы не упомянули основной (имхо) минус - крайне малочисленное и, вероятно, слабое коммьюнити. Достаточно посмотреть на https://ru.stackoverflow.com/questions/tagged/mybatis - 1-2 вопроса в год, количество ответов тоже не зашкаливает, причем по большей части - от одного участника.
Таким образом, решая воспользоваться этим фреймворком, вы фактически остаетесь 1:1 с ним и попытки использовать что-либо сложнее штатных примеров будут болезненными.
Да, но батис простой как валенок. У вас просто не будет повода лазить на SO. Я им чуть более 3 лет пользовался, и единственное, что мне пришлось гуглить - это как заменить базовую либу кэширования EhCache на что-то другое. Нашел нормальные туториалы по интеграции с Redis, Hazelcast и Inginte.
3 года назад таким явным недостатком было отсутствие поддержки R2DBC - т.е. в Spring Webflux батис не погоняешь. Сейчас могли и допилить. С другой стороны, в 21 джаве вышли виртуальные потоки. Теперь уже вопрос в том, так ли нужен этот Webflux.
Согласен. Есть такое. И здесь два варианта: либо мало кто пользуется, либо не сталкиваются с проблемами )))
Когда я входил в этот фрейворк эта проблема и была, не у кого было спросить "Что делать". Это и подстегнуло написать данную статью, а возможно даже серию с плавным погружением. По своему опыту крайних работ эта птичка вполне жива.
У нас был опыт с .net вариантом этой либы, кажется iBatis.
В общем кончилось тем, что мы поддерживали свой форк.
Основная переписка по нему идёт в гуглогруппах. И довольно активная.
Однобокая получается статья, описывает только плюсы фреймворка и нет ни слова о недостатках и подводных камнях.
К сожалению, с помощью mybatis удобно писать только совсем простые вещи. Шаг влево, шаг вправо — и все, фреймворк это либо не поддерживает, либо поддерживает очень корявым образом. Никуда не годится хотя бы то, что для банального получения списка элементов (SELECT FROM table WHERE some_id IN (?,?,?,…)) приходится городить какие-то <foreach>, вручную задавать сепараторы и все это становится совершенно нечитаемым.
Мы в итоге отказались от mybatis в пользу jooq — он тоже позволяет контролировать sql код, но возможностей у него на порядок больше.
Мы в итоге отказались от mybatis в пользу jooq — он тоже позволяет контролировать sql код, но возможностей у него на порядок больше.
Как решаете проблему со сложным маппингом нескольких сложенных сущностей после череды джоинов ?
Я помню когда читал документация JOOQ пару лет назад то они просто забили на эту проблему а все варианты которые я видел были малоприглядными мягко говоря. Подумалось тогда - зачем мне библиотека позволяющая удобно писать запросы но не дающая никаких нормальных инструментов чтобы потом результаты этих запросов человеческим образом преобразовывать в модели. Поправьте если не так.
Менее удобный батис как раз эту проблему решал удобным и простым способом.
Если я не ошибаюсь, с jooq работал год назад, то вы можете писать свой мапер, на выходе из выполнения запроса вы получаете raw данные в виде коллекции объектов, а ваш маппер их уже сериализует в какой угодно класс. Да, надо ручками кодить маппер, но с другой стороны таких запросов на проект обычно не так уж много. Мы в свое время на проекте писали многоэтажные jooq запросы с невероятным количеством join, но никогда не сталкивались с тем, что это чудовище не получалось смапить. Правда язык был котлин, там получалось изящно и немногословно написать маппер, в джаве наверное маппер получится тоже монструозным
Мапперы у нас пишутся руками и все джава-объекты там явно создаются и контролируются. Каких-то явных неудобств тут не видится, код получается простым и читаемым (несмотря на некоторую многословность).
Извините за оффтоп, не удержался, глядя на КПДВ.
При вставке плохо обтравленного слоя (птички), лучше делать внутреннюю обводку (inner stroke) размером в 1 пиксель, выбрав для неё цвет окружения (в данном случае болотный). Так слой будет смотреться поверх задника как родной.
Работаю с MyBatis лет 10. Использовал в разных проектах от относительно простых, до супер производительных 24х7 и хранилищ данных.
Основные преимущества: скорость, гибкость, предсказуемость, расширяемость и относительная простота работы со сложными объектами и запросами.
Недостатки: в некоторых сложных объектах со вложенными коллекциями неочевидный маппинг, если сложный первичный ключ особенно.
Сообщество достаточное, чтоб решить любую по сложности задачу. Большое сообщество, скорее, показывает плохую документацию, сырой продукт либо альтернативное взгляд на использование.
MyBatis инструмент для работы с SQL, поэтому не нужно от него ждать другого. Но в этом он очень хорош.
Больше всего нашу команду напрягало в myBatis то, что к SQL всё равно надо относиться как к тексту, следить за запятыми между опциональными блоками, корректировать синтаксис при смене БД.
Ушли на queryDSL, куски кода на myBatis ещё живы, но работать с ними это так себе удовольствие.
В свое время, как раз, MyBatis выбрал для поддержки нескольких баз в одном проекте. Всегда найдется какая нибудь "фича" базы, которая сводит на нет DSL фреймворк. Родной SQL проще поддерживать, т.к. всегда можно скопировать и запустить, проверить и не вникать в код.
И макросы во многих случаях заменяют DSL. А если "сахара" не хватает, то можно расширения написать.
Спасибо за статью, не знал об этом фреймворке. Но не совсем понимаю, в чём преимущество такого подхода вместо обычного jdbc + SQL. Из того что я вижу, просто код из Java перекочевал в XML. Да, мапперы иногда можно не писать и ещё пару нюансов, но глобально преимуществ мало с первого взгляда.
Там можно и в интерфейсе задавать INSERT, SELECT, UPDATE, DELETE.
Удобнее делать динамические SQL - ну естественно там где нужно, редко где конечно.
Удобнее обычного jdbc+SQL - маппинг объектов намного проще.
Когда им пользовался - в основном мапинг держал в xml файлах, остальное все в интерфейсах. Сейчас ,наверное на java string templates можно и маппинг попробовать убрать в интерфейсы.
sql надо писать под конкретную базу?
ON DUPLICATE KEY UPDATE qty = #{count} - это для mySql, похоже?
Писать под конкретную базу и дает возможность использовать ее функционал по полной. Можно писать на стандартном SQL тогда со многими типами бд будет работать. Но тут встречный вопрос как часто вы встречали смену бд в проде? Это, все же, больше прерогатива стартапов а там и JPA справится.
Если у вас продукт, который нужно разворачивать на разные базы, то здесь MyBatis, как раз, удобен. Да, этот рынок значительно уже.
Еще вариант, когда вы автоматизируете предприятие со множеством баз, т.к. разные базы испоьзуются в разных задачах и направлениях. Команда использует один фреймворк и накапливает экпертизу. Следовательно, скорость автоматизации увеличивается кратно.
MyBatis «на минималках»