Походу не)

как по мне чистиые запросы понятнее)

+, потом поменяй фреймворк и ощутишь всю связку верхнего слоя приложения с нижним, чего впринципе быть не должно

ну и быстрее пишуться)

Якщо їх правильно писати, то при цьому вони ще й безпечні, виконуються ефективно і при змінах на стороні бази даних просто так не буде можливості "віддати" зайві дані.

Это до тех пор, пока запросы вида select * from users where id = :id. Когда в базе десятки таблиц с десятками же связей, то без внятной orm свихнуться можно)

Ну от ця сама * це "смертний гріх" в sql.

А відносно проблеми зв'язаності таблиць - при адекватній нормальнізації і знанні sql такі запити теж не становлять проблем. При цьому, якщо використовувати для побудови таких складних запитів ORM, то мені страшно уявити різницю в швидкості виконання запитів.

Objection тем и хорош, что построен поверх knex-а - в любой момент узкие места можно переписать на query builder'е не отходя от "кассы" и доменной модели

Ну и рефакторинг - с чистыми sql-запросами любое переименование/удаление столбцов/таблиц в бд - это боль при сколь-нибудь большой кодовой базе

Ніхто не говорить про те, що sql запити мають бути повністю захардкодженими. У всьому іншому при перейменуванні чи видаленні стовбця в бд розробник має про це дізнатись, щоб внести зміни і при чому зробити це свідомо.

И в скольких местах это нужно сделать? Всё ли будет найдено и изменено? Ненавижу поиск по строкам при рефакторинге в проекте. В случае с orm при переименовании таблицы - я просто меняю её название в модели. Со столбцами сложнее - те же строки, но любой запрос надо заворачивать в метод модели. Т.о. поиск мест для рефакторинга будет сильно сужен

Завжди можна зберігати назву таблиці, як приватне readpnly поле всередині класу чи файлу, де знаходяться запити. Стовбці можна передавати, як масив string значень, або ж якщо для всіх запитів стовбці однакові - теж, як приватне поле класу чи ще якось.

Дак если речь про то, что мы используем классы с пропертями в виде названий таблиц, списка столбцов, изолированности запросов от остальных слоёв, то почему бы сразу не перейти на orm?) Суть - та же, плюшек - больше)

Я намагаюсь пояснити, що при будь-яких змінах програміст має бути сповіщений про це так само, як би це була помилка. При використанні ORM така можливість не завжди є.
Бо інакше це все буде працювати, як catch (error) {} і розробник буде думати, що "все чудовенько", аж поки клієнт йому не повідомить про  мутацію даних чи ще щось.
(це вже напевне крайнощі, та все ж)

Если подходить с умом, то и орм не нужна, да. Я же говорю про ситуацию, когда разработчик спрашивает - "а работает ли орм с экспрессом?" Вот при таком подходе ни о каком сознательном и профессиональном подходе говорить не приходится, кмк. Поэтому лучше взять орм, почитать доку, описать связи, положить модельки в отдельную папочку и вот уже есть какое-то подобие разделения слоёв, типизация и множество готовых методов и подходов для работы с бд, описанных прямо в документации. Такой код при прочих равных и читать будет проще, и поддерживать. А уж objection это будет, или typeorm - вопрос второй)

так а паттерн Репозиторий не разделаят на слои? можно же в нем либо использовать сиквели либо орм.

На мою думку в відео присутні пояснення, що можуть змінити думку відносно використання ORM.

обычно орм используют не всю мощь бд. и у них есть свои баги. придется изучать кроме сиквела еще саму орм.
возможно если хорошо знаешь сиквел и проект не будет менять бд, есть смысл испльзовать чисто сиквел

*сейчас будет чистая субъективщина*

sequelize - говно)

*пруфов не будет*