не совсем, лучше читай офф докусентацию. На русском почти вся устаревшая. Не критично, но все же

ну вот у тебя форма обычная. В реквестве будешь валидировать только что-то типа наличие/осутствие нужных полей, тип, рэндж и т.п., да? А валидация бизнес логики где у тебя происходит?

все что касается логики, делается в сервисах

валидация выделяется в отдельный сервис или в том же сервисе, где ты логику делаешь?

и передаешь ли ты реквест туда? или он дальше контроллера никуда не уходит?

валидация выделяется в отдельный сервис или в том же сервисе, где ты логику делаешь?

слишком отвлеченный вопрос. Например есть подписка на новости, и возможность выбрать категории. Чел ввел свои данные, выбрал категории. Данные пришли валидные. Далее запрос передается в сервис оформления подписки. И там я уже проверяю, может он подписаться на них или нет. Например он выбрал категорию эротика, а ему 14 лет. Я это проверяю и кидаю исключение, типа нет парень не можешь ты на это подписаться. Все эти проверки в сервисе.

а валидации вроде существование этих категорий, то, что категории уникальны - на уровне реквеста?

можно и на уровне реквеста проверить

по хорошему, в сервис должны прийти только валидные данные

ок, спасибо

можно и на уровне реквеста проверить

Я извиняюсь за неумный вопрос. А проверить на уровне реквеста наличине существования категории это как? Не очень понял

Я извиняюсь за неумный вопрос. А проверить на уровне реквеста наличине существования категории это как? Не очень понял

$category = Category::find($Request->category_id); if ($category == null) { // категории нет

Ребят, кто подскажет. Туплю. Условно. Есть 500 записей Прошу по 10 с шагом тоже по 10. ->offset($offset)->limit(10) . Когда отправляю $offset = 490 в ответ приходит пустой массив. Если же записей 503 к примеру, то прийдет массив с 3-мя записями. Почему так?

$category = Category::find($Request->category_id); if ($category == null) { // категории нет

в этом случае "на уровне реквеста" это в контроллере имеется в виду?

в этом случае "на уровне реквеста" это в контроллере имеется в виду?

эм, я думаю да

по мне валидации в конроллерах самый минимум должен быть

Я извиняюсь за неумный вопрос. А проверить на уровне реквеста наличине существования категории это как? Не очень понял

из кробки есть привило exists, но никто тебе не мешает написать свое правило

Ребят, кто подскажет. Туплю. Условно. Есть 500 записей Прошу по 10 с шагом тоже по 10. ->offset($offset)->limit(10) . Когда отправляю $offset = 490 в ответ приходит пустой массив. Если же записей 503 к примеру, то прийдет массив с 3-мя записями. Почему так?

посмотри какой запрос у тебя строится

Есть модель Borrower со связью credits() В ней : public function getCountCreditsBefore($date){ return $this->credits()->where('issued_at', '<', $date)->count(); } Вызов в контроллере: Credit::with('borrower')->where(... Дальше в шаблоне надо для каждого кредита получить: $credit->borrower->getCountCreditsBefore(...) И на каждый конкретный кредит делается отдельный запрос в БД Можно как-то оптимизировать запросы? EAGER LOADING почему-то тут не срабатывает

Есть модель Borrower со связью credits() В ней : public function getCountCreditsBefore($date){ return $this->credits()->where('issued_at', '<', $date)->count(); } Вызов в контроллере: Credit::with('borrower')->where(... Дальше в шаблоне надо для каждого кредита получить: $credit->borrower->getCountCreditsBefore(...) И на каждый конкретный кредит делается отдельный запрос в БД Можно как-то оптимизировать запросы? EAGER LOADING почему-то тут не срабатывает

попробуй https://laravel.com/docs/5.6/eloquent-relationships#querying-relations Counting Related Models

и еще совет, избегай названий методов начинающихся с get/set

и еще совет, избегай названий методов начинающихся с get/set

нука-нука, почему?

Гайз, подкиньте пожалуйта пищи для размышлений

Laravel Resource Дампаю $this в Resource получаю => "id" => 1 "place" => 1 "team" => "Manchester United" "played" => 10 "wins" => 9 "draws" => 1 "losses" => 0 "points" => 28 "created_at" => null "updated_at" => null ] дампаю $this->team получаю => "Manchester United" Когда хочу вывести проперти team в toArray Resource там пусто, в то же время, если вернуть return parent::toArray($request); получаю все поля

return [ 'place' => $this->place, 'team' => $this->team, 'team' => $this->team, 'played' => $this->played, 'wins' => $this->wins, 'draws' => $this->draws, 'losses' => $this->losses, 'points' => $this->points, 'team' => $this->when(isset($this->username), $this->username), 'first_name' => $this->when(isset($this->first_name), $this->first_name), 'last_name' => $this->when(isset($this->last_name), $this->last_name), ];

ERROR: S client not available

нука-нука, почему?

вот неплохая статеечка на тему, ну и видосы в конце. http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html

вот неплохая статеечка на тему, ну и видосы в конце. http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html

ну как бы от того что ты уберешь префикс у метода, ты не избавишься от того про что статья)

вот неплохая статеечка на тему, ну и видосы в конце. http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html

"неплохая" в данном случае не означает "хорошая". Потому, что это просто частное мнение какого-то чувака. Весь мир, использующий паттерн data mapper смотрит на вас с упрёком.

ну как бы от того что ты уберешь префикс у метода, ты не избавишься от того про что статья)

никто же не мешает создать более осмысленое название метода

ахахаха, хотите поржать с этого автора? Он тут про DI, как антипаттерн пишет: http://www.yegor256.com/2014/10/03/di-containers-are-evil.html http://take.ms/8iJdG

Такие примеры сводят мнение автора на нет. И приписка в конце доставляет: Impressive? This is a true object composition. I believe this is how a proper object-oriented application should be instantiated. And DI containers? In my opinion, they just add unnecessary noise.

Я, еще как, impressived с такого кода! Надеюсь у них есть время чтобы это дебажить.

Егор бугаенко особенный автор. Он пишет много интересного и разумного, но к его статьям надо очень осторожно относиться. А начинающим вообще не стоит его читать) он разумный, но хайпожор и провокатор)

Я, еще как, impressived с такого кода! Надеюсь у них есть время чтобы это дебажить.

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

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

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

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

имею и не использую сеттеры и геттры. Методам стараюсь давать осмысленные названия

имею и не использую сеттеры и геттры. Методам стараюсь давать осмысленные названия

Это все еще не отвечает на вопрос "почему стоит избегать методов с префиксом set и get в названии"