Концепция фильтрации моделей на примере Laravel

[AlexSpaizNet]

Не нравится мне идея разбрасывания SQL-ки по файлам… почему вообще контроллер должен знать (хоть и косвенно теперь через QueryFilter о том что тут присутствует SQL?

Всегда хватало простого Separation of concerns

Controller — тупой, и тупо получает запрос
RequestModel/FormModel/SearchModel (называйте как хотите) — инкапсулирует данные запроса
ServiceLayer — получает нужные зависимости и данные запроса. Вся движуха в плане бизнес логики делается тут и далее использует DAL.
DAL (Repository, DAO) — там уже строим нужную SQL-ку… хоть чистый хоть орм-ный… в одном месте.

[Maksclub]

почему вообще контроллер должен знать

Очевидно же, что в коде примера контроллер выступает как тестовый клиент, не более

[butschster]

Иногда глаз цепляется за код, который совершенно лишний и выдает глубину знаний фреймворка, например вот этот код:

protected function fields(): array
{
     return array_filter(
         array_map('trim', $this->request->all())
     );
}

Если мы посмотрим вот сюда github.com/laravel/laravel/blob/master/app/Http/Kernel.php#L20, то увидим, что Laravel уже изначально применяет функцию trim ко всем стринговым значениям для Request.

В остальном это самый примитивный вариант реализации фильтров.

[Immortal_pony]

А не могли бы Вы подсказать хорошие реализации?
И, если такие существуют, фрэймворконезависимые?

[t1gor]

А чем это отличается в итоге от EloquentFilter? https://github.com/Tucker-Eric/EloquentFilter

[zhulan0v]

Просто отставлю это здесь github.com/spatie/laravel-query-builder