Comments 6
Не нравится мне идея разбрасывания SQL-ки по файлам… почему вообще контроллер должен знать (хоть и косвенно теперь через QueryFilter о том что тут присутствует SQL?
Всегда хватало простого Separation of concerns
Controller — тупой, и тупо получает запрос
RequestModel/FormModel/SearchModel (называйте как хотите) — инкапсулирует данные запроса
ServiceLayer — получает нужные зависимости и данные запроса. Вся движуха в плане бизнес логики делается тут и далее использует DAL.
DAL (Repository, DAO) — там уже строим нужную SQL-ку… хоть чистый хоть орм-ный… в одном месте.
Всегда хватало простого Separation of concerns
Controller — тупой, и тупо получает запрос
RequestModel/FormModel/SearchModel (называйте как хотите) — инкапсулирует данные запроса
ServiceLayer — получает нужные зависимости и данные запроса. Вся движуха в плане бизнес логики делается тут и далее использует DAL.
DAL (Repository, DAO) — там уже строим нужную SQL-ку… хоть чистый хоть орм-ный… в одном месте.
0
Иногда глаз цепляется за код, который совершенно лишний и выдает глубину знаний фреймворка, например вот этот код:
Если мы посмотрим вот сюда github.com/laravel/laravel/blob/master/app/Http/Kernel.php#L20, то увидим, что Laravel уже изначально применяет функцию trim ко всем стринговым значениям для Request.
В остальном это самый примитивный вариант реализации фильтров.
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.
В остальном это самый примитивный вариант реализации фильтров.
0
А чем это отличается в итоге от EloquentFilter? https://github.com/Tucker-Eric/EloquentFilter
0
Просто отставлю это здесь github.com/spatie/laravel-query-builder
0
Sign up to leave a comment.
Концепция фильтрации моделей на примере Laravel