До этого я ещё не дошел )

Точнее пока не понадобилось

если от классов в 1000+ строк еще не возникает желание начать работу с rm -rf *, то можно и не париться пока)

Ну можно почитать про паттерны проектирования в пыхе.

Ерунда) тогда надо отказаться от моделей вообще. С учетом, что Eloquent это красивый AR, а сам AR является антипаттерном в каком то смысле и нарушает принцип единой ответсвенности по факту.
То наличие методов, в данном случае scopes, в модели более чем оправданы необходимостью выборки моделей по определенному шаблону.

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

Да, но снова таки - отказаться от Eloquent и тогда переходить на репозитории или каждую eloquent модель приводить к индивидуальному интерфейсу с которым работает репозиторий.
Просто создать репозиторий и написать там правила выборки вместо того же scope модели - это не репозиторий, а просто вынесенные scopes из модели в объект с постфиксом Repository

В добавок, сам Eloquent спокойно позволяет использовать такие конструкции и даже не краснеет:

$model1 = ExampleModel::find(1);
$model2 = $model1->query()->find(2);

И тут не вина того, что модели 1000 строк, а проблема самого способа использования инструмента.

всем привет, подскажите можно ли как-то получить ключи массива ошибок Валидатора полей, что не прошли проверку?

в data-request-success в data весь массив есть

LeMaX10 (1127.86) уменьшил карму Cabard (-33.58)

тьфу

так его) задает тут вопросы)

+ компенсация 😄

LeMaX10 (1127.86) увеличил карму Cabard (0)

->keys()

+, спасибо

Cabard (0) увеличил карму LeMaX10 (1128.86)

$model1 = ExampleModel::find(1);
$model2 = $model1->query()->find(2);

в том то и дело, что мы немного про разное говорим. Я не топлю за чисто православные паттерны.

то, что элокент так позволяет, не значит, что так надо делать. С таким же успехом можно сказать, что пхп позволяет писать неООПшное спагетти и это означает, что ПХП - это и есть спагетти. Нам же это никак не мешает кодить чисто в ООП.

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

Но это никак не мешает нам приблизить имеющуюся структуру к архитектуре Ропозитория. Мне как-то фиолетово, соответсвует ли мой класс репозитория одноименному паттерну или нет на 100%. Мне интересно хотя бы приблизиться к этому состоянию по ряду достижимых признаков, облегчив себе работу и повысив "красивость" архитектуры. И не париться с этим если это не никак не улучшит работу с конкретным проектом.

Опять же, всего лишь осветлить ситуацию по шкале черное-белое, но не грызть бамбук принимая только 100% белизну.

PHP изначально был интерпретатором для форм)) Так что спагетти это наверное его и зародило, начали с форм, а сейчас уже это нечто больше чем набор скриптов.
Функциональный подход и ООП, это разные подходы и php позволяет работать с ними обоими, правда последнее время больший вектор идет на ООП, однако функциональщина имеет место жить))) это никак не спагетти, просто другой подход который хорошо практикуется и используется в том же golang и там это так же не считается лапшой.

Вообщем репозитории юзать с eloquent да еще и без интерфейсов сущностей, это не просто не "православно", это принесет большую боль при появлении необходимости смены хранилища и вся красивость такого решения рухнет.

репозитории без интерфейсов в ларе/октябре - это не только антипатерн, но и глупость