Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Отлично написано! Респект автору!
Но всё же есть некие... так сказать "несогласия":
1. Название переменных и свойств классов таки правильней писать в snake case. И это не только на PHP. Но на PHP принято всеми. Lower Camel Case всё же для методов.
2. Вот здесь:
$category->article()->create($request()->all());
Тоже не согласен. В большинстве простых случаем это Верно, но частенько бывает необходимость расставлять значения по условиям.
Если не заполнено это поле и заполнено то поле, значит значение в 1... А если не заполнены оба, значит 2... или если заполнено То без Этого, значит 3...
Таких примеров масса в средних и больших проектах и тогда обработку, и приведение данных правильней (на мой взгляд) делать в контроллере... ведь он для этого и создан.
тогда получается что-то вроде:
$category->article()->create([
'title' => $request->title,
'date' => $request->date ? $request->date : now(),
]);
Короткий и читаемый синтаксис.
Да и более того, в Laravel каждый раз добавляется много хелперов которые мало документированы... изучайте код.
Или создавайте свои хелперы типа:
if( !function_exists('is_auth') ) {
function is_auth()
{
return auth()->check();
}
}
if( !function_exists('is_ajax') ) {
function is_ajax()
{
return \Request::ajax();
}
}
Добавлю ещё пару-тройку хелперов авторизации:
auth()->check(); // \Auth::check();
auth()->user();
auth()->id();
И добавлю от себя...
- "Правильное описание модели и связанных с ней релейшенов это уже 30% приложения!"
Изменено Cruide (07.11.2017 17:08:32)
Не в сети
Спасибо за обратную связь.
Вот здесь: $category->article()->create($request()->all());Тоже не согласен. В большинстве простых случаем это Верно, но частенько бывает необходимость расставлять значения по условиям.Если не заполнено это поле и заполнено то поле, значит значение в 1... А если не заполнены оба, значит 2... или если заполнено То без Этого, значит 3...Таких примеров масса в средних и больших проектах и тогда обработку, и приведение данных правильней (на мой взгляд) делать в контроллере... ведь он для этого и создан.тогда получается что-то вроде:$category->article()->create([ 'title' => $request->title, 'date' => $request->date ? $requ
В таких случаях нужно использовать преобразователи (mutators), значения по умолчанию и т.д. В самых крайних случаях можно использовать array_merge, но перечислять все поля (которых могут быть десятки) - это в любом случае плохо.
Изменено AlexeyMezenin (07.11.2017 17:16:50)
Не в сети
В таких случаях нужно использовать преобразователи (mutators), значения по умолчанию и т.д.
А если зависимость значений куда более сложна... и важна очередность проверки с различными переключениями в зависимости от появившихся логических изменений, а не единичные. где в зависимости от определенных входящих данных будет зависеть значение некоторых переменных, а уже от их значений зависит другие значения? Как тогда?
Мутаторов не всегда достаточно, array_merge тоже не всегда подойдёт... ведь важна последовательность логики.
Вот и выходит, что категоричность в данном случае не однозначна. Ваш вариант хорош, но не однозначен. В крупных проектах очень часто при сохранении данных нужно учитывать различные факторы которые в зависимости от логических изысканий могут меняться в процессе вычисления значений.
Конечно, часть логики можно вынести на фронт, что-то в валидатор/реквест, что-то убрать в дефолты и часть в модели, но этого бывает не достаточно и потом очень сложно искать, что и где не так.
Проще и "читабельней" всю логику описать в контроллере, в одном месте и в случае необходимости не рыться в куче файлах, а просто в контроллере поменять логику.
А так получается ООП программирование ради ООП программирования.
Можно сказать просто я хочу домой... а можно рассписать как Вы хотите в одном месте, почему Вы хотите домой в другом, в третьем как Вы будите идти домой, в четвёртом по какой дороге... а в итоге, если кто-то после Вас полезет в код, будет долго искать где у Вас описание цвета сандалей, в которых вы идёте домой.
Изменено Cruide (07.11.2017 17:44:17)
Не в сети
Проще и "читабельней" всю логику описать в контроллере, в одном месте и в случае необходимости не рыться в куче файлах
Проще, но только новичку. Читабельнее только для того, кто только что это написал. Другому разработчику или автору кода через несколько месяцев прочитать это будет довольно сложно.
Не в сети
Проще, но только новичку. Читабельнее только для того, кто только что это написал. Другому разработчику или автору кода через несколько месяцев прочитать это будет довольно сложно.
Если всё (код) нормально оформлено и грамотно прокоментированно, никаких проблем не будет. Вся логика по шагам будет видна сразу и не придётся искать где данные перебиваются. А другому разработчику так вообще проще-простого, зашел по роуту и всё увидел.
Вобщем, на вкус и цвет все фломастеры разные.
Просто я уже много раз сталкивался (и не только на Laravel) с тем, что приходится очень долго искать где и почему меняется 1 на 2. Вот именно в таких "дебрях"... в контроллере 2 строчки... и начинаешь 2 часа рыться по коду, вместо того, что бы сделать работу.
Изменено Cruide (07.11.2017 18:16:39)
Не в сети
Вот именно в таких "дебрях"... в контроллере 2 строчки... и начинаешь 2 часа рыться по коду, вместо того, что бы сделать работу.
Для этого существуют IDE. И перейти кликом по паре методов несрамнимо лучше, чем переписывать тонны кода, создавая новые баги, ради небольшого изменения функционала. Со спагетти кодом почти всегда так и происходит.
Не в сети
Страницы 1
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)
Мастер
Писарь