Комментарии 6
Напомнило скаловский slick https://scala-slick.org/
А месье ловко обошёл стороной встроенный в Exposed механизм DAO, который сильно упрощает работу с сущностями базы данных. На самом деле, используя DAO практически нет необходимости в работе с объектами таблицы напрямую. Использую Exposed более 3х лет, и, как мне кажется, автор ставил целью не рассказать о фреймворке, а рассказать о "ещё одном аналоге, Hibernate".
Иногда, всё же, есть причины делать так, как описано в данной статье. Дело в том, что DAO несколько медленнее. Плюс для DAO класса нельзя нормально настроить сериализацию, потому как у него всего-то одно поле хранится непосредственно в экземпляре - это id. Поэтому способ доступа весьма похожий на то, что описано в этой статье, я сам иногда использую в случае, если нужно сохранять большое количество сущностей в БД сразу из сети. То есть десериализовал и сразу в таблицу. Большими пачками в Batch запросах. В таком случае Вы заметите сильное преимущество перед DAO по скорости. В других же случаях вполне можно использовать и DAO. Особенно хорош DAO, если он один раз читается из БД и долго потом используется без изменений.
Звучит разумно, но скажите пожалуйста, где я говорил, что нужно ВСЕГДА использовать DAO? Я просто указал на то, что автор статьи его вообще не упомянул. Это раз.
Во-вторых, если уже говорить про сериализацию, то автор использует просто методы расширения. И плевать, что такие методы могут знатно подпортить нервов, когда они вызываются не в том месте, а именно - когда ResultRow не содержит нужных атрибутов. fun ResultRow.toContact(): Contact = Contact(
id = this[ContactEntity.id].value,
type = ContactType.valueOf(this[ContactEntity.type]),
value = this[ContactEntity.value],
userId = this[ContactEntity.userId].value
)
Типобезопасно, моё почтение. Скорее "Типо" безопасно.
И, касательно медленности, под капотом там такая же работа с таблицами. Буквально, те же методы. Да и для создания Entity там уж не так много работы лишней не выполняется, только заполнение прототипа данными. Но окей, если доступ к полям объекта таблицы, чтобы этот прототип описать, такая уж тяжёлая задача, то почему месье вообще не пытается использовать корутины, чтобы максимально быстро выполнить запросы? Серьёзно, где они?
П.С. Все операции вставки кэшируются в Exposed, так что один фиг, вставка в таблицу произойдёт только перед считыванием/изменением данных, так что разница в скорости работы обоих методов буквально виртуальная ибо для конечной бд они одинаковы. Но да, документацию читать в наше время - комильфо, коллега.
Прошу прощения, если я задел Вас. Я просто уточнил про варианты использования Exposed без DAO. А на счёт того, что написано в статье, я согласен. Там далеко не всё норм. В частности, методы расширения для ResultRow меня самого напрягли, но я не стал уже придираться.
А по поводу производительности DAO я говорю из личного опыта. Я использовал Exposed+PostgreSQL. И на нём пакет вставок происходит значительно быстрее, чем много одиночных вставок, по понятным, надеюсь, причинам. И я в своём комментарии писал именно о таком использовании. Кроме того, DAO ещё нужно создать, а это дополнительная работа. Да она не велика, но при плотном потоке данных становится заметна. При достаточно плотном потоке данных с максимальной оптимизацией и корутинами мне удавалось выжимать разницу в разы (2-3 раза) в сравнении с DAO. Собственно, так я и пришёл к этому. Изначально я использовал только DAO. Но в некоторых местах мне сильно не хватало производительности и, что было самое странное, БД выжимала далеко не всё, что могла. Я начал экспериментировать, сначала с оптимизацией DAO, потом и с Exposed SQL DSL. Не только документацию, но даже исходники Exposed DAO изучал. Сильно уж мне в этих узких местах нужна была большая производительность.
Пишем приложение на JetBrains Exposed