Абстракции потекли неуспевши сформироваться.

Я такие проблемы решал так:

Если запрос без агрегации и выбор идет из одной таблица, то ипользуется такой билдер

$query = $queryFactory->get('Users', 'FindBy');
$query->setCriteria([
    'contact_id' => [1,2,3],
    'deleted' => $query->expr('NotNull'),
    'date_entered' => $query->expr('LessOrEqual', '2015-12-22'),
]);
$query->fetchAll();

А если же начинается какой-то хардкор, то пишется на чистом скуле и обварачивается объектом

$query = $queryFactory->get('Users', 'UserForDeleteInactive');
$query->setPeriod('1 week');
$query->fetchAll();

Очень гибко, а главное, не течет sql через такую абстракцию. Минусом является, один запрос - один класс. Но плюсов намного больше.

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

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

В том и дело, чтобы предоставить выбор. Какие плюсы важнее, те и использовать. Я как то писал свою историю, я на работу устроился потому, что сбежал предыдущий программист. Который рассуждал так, как ты:

В результате на хайлоаде начали падать сервера. После моей оптимизации ресурсоемкость снизилась в 20(!) раз. Так что это тоже важно - иметь возможность писать оптимально.

Вопрос собственно был не в том, я наверное неверно сформулировал. Вопрос следующий:
Какие могут быть подводные камни, если немного отойти от чистого паттерна.

Вообще я понял уже, что ничего страшного в этом нет, и что эта возможность есть в мейнстримах. Так что спасибо за ответ.


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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

User::select(['num' => $command->expression('MAX(id)')])

AR - это такой паттерн который танцует от таблицы. Он знает какие поля есть, какой у них тип, какие из них - pk и т.д.

Например в yii2 ты можешь себе выбрать что то дополнительно в модель, но для этого надо завести самому доп поле, если его нет то игнорируется. И с теми полями(сохраняемыми) из БД это поле не пересекается.



_____________
There never was a struggle in the soul of a good man that was not hard

А можно вот это поподробнее, откуда знает?

Вот в том и вопрос, чтобы не заводить дополнительных полей. Как из запроса пришло, так и должно быть в объекте. Это примерно как fetchObject() в PDO. Только он не запишется в таком случае.

Вобщем то я пошел другим путем, от обратного. Хочу сделать пометки. Не заранее заводить поле, а по мере надобности помечать его на игнор.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Тогда почему ты не используешь популярные решения? Ведь по факту, ты сейчас расписываешься, что не закрываешь проблемы, которые есть в популярных решениях, а попросту делаешь как сделано у них. Зачем тогда писать своё решение?

Давай ты мне скинешь исходники того продукта (который не держал нагрузку), я посмотрю, а потом уже сделаю вывод и правда ли там все падало из-за применения ООП. Я гарантирую, что дальше меня эти исходники не пойдут.

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

Так а это не проблема. Это наоборот хорошо. Я не нашел этого в доках, думал что нет такой возможности, захотел сделать. И спросил на всякий случай. Оказывается есть, ну и славненько. А свое решение для души. Ну нравится мне, что поделать. Может и правда сделаю что то оригинальное в процессе.

Да какие исходники, лет 8 прошло уже. И не в ООП там было дело, а в реализации. В двух словах, нужно было вывести на странице около 50-ти анкет. Данные брались из разных таблиц. Вот он сделал анкету самостоятельной сущностью и получал их по одной. В итоге вышло около 300 запросов только по анкетам, плюс еще другие.

Я почему вспомнил, потому что ты сказал

У него было не на класс, а на объект. Но не суть, я не вижу смысла как то изгляться снаружи, если можно сделать все автоматически.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

На продакшене конечно из кеша структуру берет.

Затем что когда структура таблицы будет меняться, чтобы класс AR модели не пришлось переделывать, а бралось на лету.
Не знаю, ты у себя , вручную что ли собрался заставить пользователя вводить и обновлять метаданные?


_____________
There never was a struggle in the soul of a good man that was not hard

Нет, не валидация. Валидация не относится к AR.
Тебе надо мапить int в базе в int в php, float в float, строку в строку, json в json, SQL NULL в php null и обратно и т.д. Для этого надо знать тип столбца/переменной.

_____________
There never was a struggle in the soul of a good man that was not hard