Говорить "А — плохо", не вдаваясь в контекст — дурость

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

по поводу экранирования - сори, но ерунда какая-то... Уже давно все модули работы с БД умеют делать параметризацию данных, и сами проводят все необходимые операции типа экранирования, так что в данном аспекте полный паритет с ORM... А по поводу А - плохо, используй Б - ну-да, интересный подход... Т.е. если человек юзает что-то древнее и медленное, и давно есть лучше и быстрее и лаконичнее... и если реально отличный специалист ему  на это указывает... то спец = дурак по вашей логике...

>вторая часть сообщения
Все ясно, вы — дурак

а это уже прямое оскорбление =) так что стоит еще посмотреть кто тут кто...

Ваш пример — разделение на чёрное и белое, не вдаваясь в контекст. Разработчик А может использовать более медленную библиотеку Х, поскольку она решает проблему I, а разработчик В о такой проблеме даже и не думал

>не вдаваясь
Если конкретнее, вы контекст даже и не описали. Конечно, в ситуации, когда две библиотеки с разной производительностью решают одинаковые проблемы, то выбор очевиден, а спор заведомо не имеет смысла

Вы совершили именно ту ошибку, которую я и назвал проблемой подобных высказываний

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

Утро доброе госпада работал кто-то с graphql ? Вопрос в следующем правельно ли я понимаю что вызывать функции ( допустим регистрации юзера) надо в "resolve" ?

В вопросе с orm же все довольно "просто", если устраивает качество/оптимизация генерируемых запросов и скорость их выполнения, и допустим оверхеад создаваемый orm, то используй orm и не заморачивайся)

Мне кажется всеже выгоднее просто функции в бд написать да их дергать  через драйвер

Господа неужели все на ресте сидят ?

Реакту больше не нужно

Да, как вариант, но мы тут рассуждали о путях "с orm" и "без orm"

Обычно орм используют на стартапах, пока объем данных не появился, потом возвращаются чуть ли не обратно к хранимкам. Вообще не вижу юз кейса для орм где-либо, кроме новых проектов, когда нужно сделать быстро мвп, либо в микросервисах, которые состоят из не более чем двух таблиц, т.к. там орм вполне может решать большинство задач. Метод save ещё полезен у орм, хотя у того же typeorm он с подводными камнями, вроде все. От ошибок орм защитить не может, от ошибок защищают знания и опыт. Сам я использую орм, просто на текущем проекте в большинстве мест орм справляется, но в некоторых местах уже отказывались из-за соображений о производительности, там перешли в итоге на нативный модуль.

Да, в большинстве своем к этому все и приходит)

+ ничто не мешает использовать механизм миграций вне конкретного орм

Вы пришли к тому, что у использования ORM есть такие же сценарии, как и у отказа от ORM, что я и пытался донести

Всем привет.. Ребят подскажите кто как пишет тесты?