Ни в коем случае) я писал про ORM  на примере Entity Framework, когда есть сложное многоуровневое наследование с кучей классов и с хранением в виде TPT, TPH - тогда ORM начинает сходить с ума и создавать монстров.
Kata немножко не об этом, она не совсем про ORM.

Так а как то, что я написал, связано с ОРМ? Тот же квери-билдер написал, вообще разницы не вижу.

Я про модели, маппинг и прочее не писал

Тогда пардон, проф деформация , вижу ORM, пишу про ORM)

Разговор с того и начался, что написали "пора съезжать с ОРМ, пока не поздно", а я ответил, что "можно из ОРМ юзать только квери-билдер". И меня стали клевать))))

Понял вопрос, а в чем проблема с if(){}else{} ?

в догонку напишу, что при проектировании 6NF специально создаётся каталог, в котором описано каким образом для 6NF-схемы генерировать запросы в 5NF (ибо приложению в 6NF не удобно). и генерация запросов по каталогу – это примерно то, что вы обсуждали. кому-то удобно в базе процедурами, кому-то из приложения / кому-то важна логика, а кто-то просто поля из словаря маппит. так, к слову…

Писать много, пальцы устают.

Дело не конкретно даже в этих условиях, а в том, что очень часто разработчики внутри условий строку с запросом по кусочкам собирают. Звучит безобидно, пока таких условий не становится много. В итоге путаница со скобками, параметрами, а в некоторых случаях и запрос получается невалидным. Далее разработчик видя, что получается какаха, реализует шаблон проектирования "строитель" (если он знает шаблоны проектирования, конечно, и ему не плевать на качество кода).

Потом он думает "хм, а мне бы с объектами было удобней работать, чем с массивами" - и прикручивает туда самописный маппер результатов запроса на объекты. В итоге человек пилит свою ORM (простейшую, т.к. сделал квери-билдер + маппер), даже не зная об этом, и продолжает бить себя кулаком в грудь, крича, что он ненавидит ORM, и что они не нужны. Это я не прикалываюсь, если что. Реально неоднократно таких разработчиков встречал.

А ну это уже проблема стандартов внутри самой команды и наличия CodeReview, где более мудрые товарищи бамбуковыми палками по пальцам за такое бьют

У изобретения своей недоORM есть большой плюс: нет риска того, что завтра понадобится сделать простенький подзапрос, который в настоящую ORM ни фига не влезает без двух суток ковыряния исходников.

Человек и пишет изначально что вместо ORM, можно использовать квери-билдер. я тоже сначала мимо прочитал))

В самописную он точно так же не влезает. Ещё и документации нет, тестов, а ещё sql-инъекции

Я не могу ни писать на квери-билдерах что-то сложнее элементарной выборки, ни читать уже написанное. Очевидно, плохой с меня программист.

Один из тех разрабов был руководителем разработки (и по возрасту почти в 2 раза меня старше был на тот момент). И хрен что ему докажешь. Я посмотрел на это всё - и свалил через пару месяцев.

Ну все библиотеки квери-билдеров, которые я встречал, имеют те или иные ограничения. Какие-то более гибкие, какие-то менее. В любом случае где-то прибегать приходится к чистому SQL, но всё равно это сильно далеко от его повсеместного использования в проекте.

У меня в коде всегда мешанина из чистого ORM’а для элементарных запросов, чистого SQL для творчества и ручных prepared statements для СКОРАСТИ. Жив, здоров.

Краткое резюме?) квери-билдеры для чего-то простого и средней сложности, а сложное уже на языке самой СУБД.

Я к тому, что «код на квери-билдерах» невозможно ни читать, ни писать.

А мне чистый ORM-подход не нравится, т.к. всякие findBy с lazy-лоадингами - ну его нафиг. Квери-билдер надёжней в этом смысле