А смысл тогда в АР?)

Все очень зависит от того, что именно ты хочешь сделать. Пока что вообще ничего не понятно

Ты пытаешься говорить о том, что что-то неподходит и даже рассуждаешь об анемичной модели

А смысл тогда в АР?)

как наличие бизнес логики в модели соотносится с АР?)

Но никаких деталей предметной области и бизнес-логики не раскрываешь

Так нельзя

- Как сложить 2 числа? - 2 + 2 - Но мне надо переиспользовавть функцию - Ну засунь в функцию - Я слышал, что функция из 1 строки - плохо

- Как сложить 2 числа? - 2 + 2 - Но мне надо переиспользовавть функцию - Ну засунь в функцию - Я слышал, что функция из 1 строки - плохо

Передергиваешь

абсолютно нет

Ок, а что у вас в АР лежит? Помимо релейшенов и скоупов?

Ок, а что у вас в АР лежит? Помимо релейшенов и скоупов?

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

Это норм. В целом про сервис бана, там все ок, если сервис просто отвечает за то, что нужно например рассылку сделать и ещё какую логику помимо бана. Я к тому, что модель должна уметь сама себя банить. А то, что происходит помимо этого, это уже логика сервиса, или могут лисенеры какие-то быть, которые слушают событие бана. Я думал, ты пропагандируешь вариант с тем, что АР - просто набор релейшенов, скоупов и запись в бд, у которой мы можем дергать поля, т.е. просто структура

Это норм. В целом про сервис бана, там все ок, если сервис просто отвечает за то, что нужно например рассылку сделать и ещё какую логику помимо бана. Я к тому, что модель должна уметь сама себя банить. А то, что происходит помимо этого, это уже логика сервиса, или могут лисенеры какие-то быть, которые слушают событие бана. Я думал, ты пропагандируешь вариант с тем, что АР - просто набор релейшенов, скоупов и запись в бд, у которой мы можем дергать поля, т.е. просто структура

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

эти споры куда положить логику, наверное уже десятилетия ведутся. Столько статей написано, столько видео снято. И везде примерно одно и тоже мнение. Но всеравно каждый приходит и спрашивает. Есть простой ответ, если тебе не надо разделение, не делай. Если ты в своем коде через 3 месяца спокойно определяешь где что и как делается, то все норм. Если внесения нового функционала, не вызывает никаких проблем, то все норм. Иначе ты сам придешь к верному пониманию что и как декомпозировать. По традиции скидываю 2 ссылки :) http://slides.elisdn.ru/2017/yiiconf-semantic/#/ http://developer.uz/blog/layered-structure-for-yii-app/

парни какой тип данных использовать для хранения изображения бд ?

парни какой тип данных использовать для хранения изображения бд ?

не надо так делать (

не надо так делать (

а как надо? подскажи

парни какой тип данных использовать для хранения изображения бд ?

в фс храни, а в базе путь

а как надо? подскажи

путь клади в базу

в фс храни, а в базе путь

в фс ? а можно расшифровку 🙈

путь клади в базу

спасибо

файловая сисема

аа

файловая сисема

утро, спасибо)

если очень много файлов, используй что-то типа aws например

если очень много файлов, используй что-то типа aws например

оно платное? и да, будет минус трафик с картинок от поисковиков (

если очень много файлов, используй что-то типа aws например

какой тип в миграции написать для пути?

Раз начали говорить что-то про архитектуру, то ещё накину: где у вас валидация? Только реквест?

Раз начали говорить что-то про архитектуру, то ещё накину: где у вас валидация? Только реквест?

смотря что валидировать, если данные реквеста, то да.

какой тип в миграции написать для пути?

string

string

спасибо

string

я по правильному пути иду ?

я по правильному пути иду ?

ну да) чтение документации это самый правильный путь)

и страница тоже правильная открыта

если в двух словах, причел файл, сохранил его в storage, путь сохранил в бд

если в двух словах, причел файл, сохранил его в storage, путь сохранил в бд

спасибо)

смотря что валидировать, если данные реквеста, то да.

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

я по правильному пути иду ?

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

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

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

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

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

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

слишком отвлеченный вопрос. Например есть подписка на новости, и возможность выбрать категории. Чел ввел свои данные, выбрал категории. Данные пришли валидные. Далее запрос передается в сервис оформления подписки. И там я уже проверяю, может он подписаться на них или нет. Например он выбрал категорию эротика, а ему 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 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), ];

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

вот неплохая статеечка на тему, ну и видосы в конце. 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 в названии"

Мне нравятся его темы про управление проектами и менеджмент)

И процессы в разработке и качество продукта

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

как минимум мешает пониманию общего смысла. Вышестоящий пример getCountCreditsBefore дает нам понимание того что мы получаем какую то внутренню часть объекта, что на самом деле не является правдой. На деле мы вообще делаем запрос к стороннему объекту. Мы должны попросить объект просто посчитать кол-во связанных данных.

как минимум мешает пониманию общего смысла. Вышестоящий пример getCountCreditsBefore дает нам понимание того что мы получаем какую то внутренню часть объекта, что на самом деле не является правдой. На деле мы вообще делаем запрос к стороннему объекту. Мы должны попросить объект просто посчитать кол-во связанных данных.

Это конкретный пример. И все еще не ответ на вопрос для всех случаев.

Это конкретный пример. И все еще не ответ на вопрос для всех случаев.

ну я написал про то что стоит избегать. Естественно если если это осознная необходимость никто тебе не запретит именно так именовать