его нельзя не использовать. его используют все (если клиентский язык ОО). но не только лишь все делают это осознанно

привести пример сможешь, где он ограничил твои возможности? только вменяемый пример.

результат запроса в объект пихаещь по типупро сохранение аналогично.

это называется копипаст. кому-то он приятен

блеать, ему это и не надо уметь. а Select/Update/Delete - это 90% работы с РСУБД

ОРМ не отменяет реряционную модель, о чем говорится в букве Р. так что ты просто очередной неосилятор копипастер.

колоться но продолжать есть кактус никто не предлагает. там, где надо "все возможности СУБД", там их и надо использовать. но, повторюсь, Select/Update/Delete - это 90% работы с РСУБД

и первый пост чукча-нечетатель не читал: если клиентский язык ОО - то ОРМ, хочешь-не-хочешь есть, просто оно либо говно-самоделка-копитастная, либо нормальная библиотека, к которой прилагается мозг

вот то-то и оно

1) если без "архитектура построена на серверной логике (хранимки)" - то это просто нежелание, необъясниемое и беспощадное велосипедостроительство
2) и даже тут часто возникает задача отображения. хранимка хранимке рознь.

сам по себе sql не интересен, это как F# (или хаскель) в интерактивном режиме - нужен результат, а не задротство. а так - magic string антипаттерн.

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

и тогда будет счастье

и тогда не будет этих священный войн "говно ваш Java Script, ОРМ для дебилов ..."

деда, можно это все делать и без ебли. можешь привести пример своего секоса?

и да - мне прикольно эксперементировать, и нет - я на денег от него живу

давай проанализируем этот интерфейс.
1) что возвращает метод - множество записей. Но! в клиенском языке нет множества записей, а есть коллекция объектов. внезапно, да?
- думаем А подразумеваем Б. т.е. абстракция есть, а реализация размазана копипастом
2) такой же объект может возврашаться не в коллекции, а один, т.е. User::getUser. т.е. уже 2 места с одинаковым кодом, где происходит трансформация. ну ладно куй с ним напишет что-то вроде getUserFromSQL
- но еба, этим то все не ограничивается, см. далее:
3) User::saveUser (да, постфикс лишний, контекст определяет. определяет ведь? да? или User::save сохраняет жирафа? но к это чуть ниже). Что? опять трансформация только в обратную сторону? ну и пох, напишем руками
- и таких 2000. как во владивостоке? ну и пох - наше дело маленькое, мы ведь программисты, а не маги волшебники
4) хм, а ведь User::getList тут должен возврашать пользователя "просто пользователя", а там - пользователя и связанные с ним сущности, причем не только 1-1. да и пох, напишем User::getListFithPosts, добавим еще скуэля

...
N) у пользователя добавилось булево поле "использует ли он ОРМ"
- и нам придется...

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

и это только маленькая толика.

вот тебе и мощь ООП. это называет копипастный говнокод

а мне и с мегамэтрами не влом вести этот диалог. я в свое время так и научился

а мне приятно видеть что и в .NET (там можно всяко, но везде или EF, или NH или еще что-то) и в Java (Spring, и не только) этот подход культивирован. наверное у дураков мысли схожи.