Еще один вопрос позвольте. Куда обычно вы выносите работу с

моделью из контроллера? В репозиторий класс (как сервис)?

не то, чтобы я был экспертом, но подобную логику я оставляю в контроллере без проблем. а вот валидацию всегда выношу в Request классы. ну и да, time+extension это риск перезаписи файлов, которые были загружены одновременно.

Довольно странно читать это на канале Laravel Pro

это вполне нормальный вопрос, вообще по больше бы таких со здравыми комментами. всегда интересно посмотреть кто и как делает. я с ларой пару лет, до этого мыслил симфонией, игнитером, yii, собственными фреймворками на заре разработки итп, но даже с с многолетним опытом в php у меня бывают глупые вопросы по ларе, просто убедиться, как кто делает и почему. можно считать себя про, но без обмена опытом, это про на уровне 127.0.0.1, не дальше

Я не сказал, что вопрос не нормальный, мне кажется, что это уровень новичка. Ваш ответ меня так же удивил.

я не использую сервисы, предпочитая либо прописывать логику в контроллере, либо частую логику выносить в модели/ивенты. меня наоборот смутило, что кто-то пишет валидацию в контроллере. в этом же и прелесть, каждый меняется опытом, рассказывает как у него, в итоге складывается картина, как кто делает, почему и для чего. слышал, что по уму всё это выносить в сервисы, всю работу с моделью. посмотрел реализацию, мне не зашло, продолжаю писать логику в контроллерах, ибо как по мне, там ей и место, по крайней мере для меня. Опять же, часть логики в ивентах, часть в моделях, но в общем случае я не вижу смысла создавать сервис для сохранения одного параметра, условно. буду рад, если вы расскажете для чего это делаете вы, вполне вероятно, что я передумаю ) например у меня лара только api, фронт на реакте и я не использую livewire или шаблоны стандартные итп. мне проще написать реакт приложение, которое общается с ларой исключитьно по http/websocket апи. слой http закрывают контроллеры, слой websocket закрывают ивенты и броадкаст. для меня намного важнее описать каждый реквест (валидацию) в отдельном файле. даже те параметры, которые могут быть, а могут не быть, я описываю в реквесте, типа 'checkbox' => ['nullable']

Смотрите, Вы так красочно описали валидацию, заметили, что она должна быть в отдельном классе, и тут же соглашаетесь с тем, что какая то логика содержится в контроллере.. Мне так же хотелось бы прочесть ответы профи по ларе.. Это всё же канал PRO, а не для начинающих..

я поэтому и написал, что какие-то вещи для меня важны и я понимаю, почему они для меня важны и поэтому их юзаю, например реквесты. при этом я не понимаю, зачем мне выводить логику с моделью из контроллера, который этой логикой по сути и рулит. поэтому на вопрос человека, выносить это в сервисы или нет, я и ответил, что лично я не выношу, а вот реквест бы вынес. я на php пишут с 3-ей его версии, я видел много реализаций и да, laravel сейчас мне кажется самым удачным инструментом, который задаёт высокую планку для других языков. инструментов уровня laravel нет ни в го ни в питоне, ни тем более в nodejs, который я тоже люблю. и эта группа, я надеюсь, создана для обмена опытом ) вопрос был новичка в ларе, но не факт, что человек новичёк в разработке. понятно, что есть паттерны разработки и прочее, но так же есть задачи, которые нужно реализовывать. если метод контроллера, который создаёт сессию для файла (как пример в вопросе у топикстартера) это условно единственное место, где это делается, я не вижу причины выносить это в сервис. и буду рад услышать, что я не прав, если мне объяснят почему. если проект реализуется через сервисы, очевидно, они нужны и для одного случая, да. я привык делать методы контроллеров таким образом, чтобы действия в моделях были уникальными, либо делались через ивенты. я не доказываю свою правоту, я пришёл к этому выводу в процессе разработки и могу ошибаться )

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

Хм, поделюсь своим опытом, раз знатоки молчат =) Задача контроллера вернуть ответ и всё. Логика же должна находится где либо ещё! К примеру, есть такая CMS как Opencart, хуже **** придумать сложно! Там контроллеры достегают 10к и более строк. Чтобы разобраться в этом, уйдут месяцы! Там нет ни каких всем известных принципов. Сервисный слой не панацея! Но как отдушина, это имба. Есть такой шаблон как Porto, шикарная вещь, только не стоит смотреть на реализацию Apiato

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

Так или иначе мы начинаем пользоваться чей-то реализацией! Любой шаблон, это чья то реализация.. Что касается скрина, я бы вынес проверку в соответствующий класс и туда добавил вызов класса ДТО. Сохранение картинок это однозначно отдельный класс.

даже если это единственное место в проекте, где есть сохранение картинок? ))) про реализацию полностью с вами согласен, я долгие годы посвятил оптимизации mysql, есть вещи, которые мне непонятны в ларе. я видел PR, где парень предлагал адекватное решение, которое убирает updated_at из timestamps(), т.к. оно там не нужно. и где тейлор писал, что это протеворечит философии лары. прав ли тот парень в плане оптимизации mysql — очевидно. есть кейсы, где тебе не нужен updated_at в моделе и где он будет занимать 4 байта лишних данных на каждую строку в базе. прав ли тейлор? очевидно ) это скорее узкое требование для высоконагруженных систем, которое проще реализовать иначе, нежели чем внедрять в лару (хотя я бы поспорил). поэтому да, мы все следуем правилам, которые нам навязали.

Да, однозначно! Отдельный класс для загрузки. Мы не можем знать, кто после придёт теребонькать эту загрузку.

Если контроллер простой и в нем нет дублирующего кода, зачем создавать отдельно под него сервис? Если контроллер сложный и функционал внутри может повторятся, то да, тут разносим по сервисам и классам. Не нужно тупо следовать каким-то убеждениям, если не понимаешь зачем вообще такое делается.

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

Мы так же не можем знать на перёд, какая задча будет завтра.

Скорее всего, мы не можем знать как будет приложуху развиваться

это скорее как стоять на красный светофор ночью в небольшом городе при отсутствии траффика. вроде как правила, но с другой стороны полная чушь. а с третьей стороны — не сложно. скорее если принято так делать в команде — проблем с этим быть не должно. у меня лично так не принятно, поэтому мне это странно

Есть книга, где описывается подобное!

преждевременная оптимизация — крень всех зол. (с) дональд кнут

Завтра и вынесешь в сервис если потребуется )

+1, решай проблемы по мере их поступления. иначе можно 6 дней тратить на реализацию фичи, которая заняла бы 1 день, а в итоге она окажется вообще ненужной. переделывать тоже бесит, но чаще всего ты, как разработчик, понимаешь наперёд, потребуется оно дальше или это просто прихоть бизнес-аналитиков

А почему бы сразу не выкинуть в отдельный класс для маштабируемости?

Согласен. Иногда разработчик может и не понимать и не знать на перед и, возможно, усложнит простую задачу более сложной реализацией.

За частую так и есть! Но что тебе мешает выкинуть в отделку? В этом и есть решение

там, где он не нужен, просто: class MyModel extends Model { const UPDATED_AT = null; } и поле из таблицы можно выносить на мусорку =)

попробую. пол года назад читал PR на эту тему, тэйлор высказался, что это противоречит философии. в миграции вместо timestamps руками создаёте created_at?

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

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

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

ну опять же, тема вечера "везде хорошо своё решение". где-то без логики в мускуле можно и нужно справляться. а где-то просто глупо без неё

Почему такие интерсные обсуждения ночью происходят?) Тож интересно мнение остальных. Сам тоже кучу времени потратил в поиске какого-то баланса как правильно и как мне было бы не больно =). Пока держу в голове что контроллер лишь посредник, можно сказать менеджер которому пришли данные и он должен передать одному ответственному работнику и получить с него результат. Если задача простая (поменять адрес на сайте) и он знает конкрентного ответственного работника (модель), то тут наверно все просто должно быть. Если же для задачи нужно несколько работников (дизайнер, фронт, бэк, девопс), то уже делают пул работников со своим менеджером(сервис) и контроллер-менеджер общается только с ним. И таких пул менеджеров уже как-то можно мониторить, тестировать и все в таком духе. Как результат главный менеджер не забивает голову логикой и тем более не общается с большим кол-ом работников. Но наерно опять же все зависит насколько большая компания и может ли она себе позволить такую иерархию. Аналогия наверно так себе) При прямом бесконтрольном общении контроллера с моделью большой риск что со временем/задач или контроллер начнет расти или модель начнет набирать много сомнительной логики. YAGNI, DRY, KISS, SOLID и тп все конечно стараешься в голове держать, но... 😏