1е правило безопаности в веб - проверять весь пользовательский ввод на бэке.
Возможность бэкенд тестирования
Возможность взаимосвязанной логики методов валидации
Возможность очередности методов валидации
Другой функционал ларавел реквестов (например пре-валидация)
Возврат ошибок в едином виде на всех языках с 5 символьным кодом
Соблюдение стандартов для других разработчиков
Удобство поддержки
Возможность не писать велосипеды
Мне очень интересно, как правильно провести валидацию полей формы
еще раз - max:500 в реквест файле. Подробнее в доке
Иван Родичев, max:500 написать слишком? 1 слово. И Ларавел автоматом сделает валидацию и вернет сообщения на всех языках. И не из контроллера, а в файлах валидации. Рекомендую поизучать Ларавел там много всего интересного. Я 2 раза пишу про размер строки - в тестах и в реквестах. Иногда на фронте, чтобы показать реалтайм кол-во символов для текстов. Это оверхед. Можно было написать под полем: "Пожалуйста не пишите более 500 символов, если вы хакер закройте сайт и сдайтесь полиции". С такой логиколй Ларавел не нужен т.к. там контроллеры роуты какие-то можно гораздо проще и быстрее делать (например, поливать на странице).
Иван Родичев, это ларавел-среда сказывается. Проехалась по людям и потом они такое пишут в беспамятстве.. Нормальные разработчики не будут посвящать целый раздел доков какой-то валидации и пилить под нее отдельные классы с кучей методов. Эти велосипеды и говнокод от непрофессионализма, не знают про правильные способы (не прочитали пока твой ответ (( Вся надежда на гугл (поиск и переводчик). Что тейлор найдет осознает как заблуждался и выкинет это говнище
Максим, api это не просто файл роутов для ajax. Это файл с мидлварями для апи (см RouteServiceProvider). Там нет проверок, сессий нужна отдельная авторизация для маршрутов и т.д. Правильно посмотреть список мидлварей в kernel для api группы, чтобы оценить подойдет это для запросов или нет.
Дмитрий Байбухтин, $users->update($model) это не читабельный класс. Это ненужная путаница. Читабельный $user->update($data) который Ларавел уже придумал. Выносить в сервисы - да, но не дублировать методы Laravel.
Дмитрий Байбухтин, в сервисы имеет смысл выносить какие-либо процессы, а не повторять методы Ларавел. Код $users->update($model) говорит только о том, что здесь выдуман очередной велосипед в который нужно лезть, чтобы понять что это и зачем
65536, что вы там мутите или курите я хз. В Ларавел куча своих методов в моделях и куча примеров как их использовать. Не нужно выдумывать ни абстракции, ни PostCreated ни еще что-то. За вас все уже придумали.
vism, это уже вопросы перфекционистского отношения к работе, а не необходимости для новичка. Новичку тупо читать всю доку без других действий на старте вредно т.к. грузит левой информацией при наличии незакрытых простейших вопросов. Я юы советовал вначале ларакаст смотреть и просто понять где щелкать, а с докой ознакомиться как со справочником (структура, какой функцуионал ит.д.). Понятно, что у каждого свой подход и опыт, я свое мнение не навязываю.
UksusoFF, cогласен) Если вместо ларавелевских способов используются свои велосипеды это 100% говнокод. Я же не говорю не читать. Читать. Но читать доку сразу полностью и читать поэтапно то что тебе нужно в процессе практики, ларакаста и т.д. это разные чтения. По дороге на работу можно просмотреть чтобы узнать возможности фреймворка. А не тупо все читать вместе с ассертами тестов, пакетами ит.д.
1е правило безопаности в веб - проверять весь пользовательский ввод на бэке.
Возможность бэкенд тестирования
Возможность взаимосвязанной логики методов валидации
Возможность очередности методов валидации
Другой функционал ларавел реквестов (например пре-валидация)
Возврат ошибок в едином виде на всех языках с 5 символьным кодом
Соблюдение стандартов для других разработчиков
Удобство поддержки
Возможность не писать велосипеды
еще раз - max:500 в реквест файле. Подробнее в доке