Laravel - фреймворк с лаконичным синтаксисом и местами он пытается угодить всем, предоставляя разные способы написания одного и того же кода, что часто приводит к «laraway» спорам.
Здесь я хочу рассмотреть сомнительную функциональность, которой нет в документации, но тем не менее её применяют - это магические методы, речь не про саму "магию" в php, а про альтернативный синтаксис некоторых методов, например, where()
1// regular syntax2Post::query()3 ->where('id', 1)4 ->where('status', 1)5 ->first();1// alternate magic syntax2Post::query()3 ->whereId(1)4 ->whereStatus(1)5 ->first();Обычно у разработчиков первая реакция "ух ты, а так можно было?". Да, действительно так можно, но не нужно.
# Читаемость кода
Сначала код может показаться более "гладким", но выглядит он так только в простых примерах, с простыми именами полей. Когда условий значительно больше, а имена становятся реальными, то читаемость кода падает.
В первом примере (обычный синтаксис) мы можем очень быстро, не вчитываясь, пробежаться глазами и найти все where() и поля по которым происходит выборка. Это происходит благодаря визуальному отделению имени поля от имени метода и помогает в этом ещё и подсветка.
Во втором примере, нам придётся вчитываться в название метода и искать где заканчивается where и начинается имя колонки, и подсветка нам в этом не поможет.
Субъективно, скажешь ты? Ок, двигаемся дальше.
# Поддержка IDE
Следующая проблема альтернативного синтаксиса - это поддержка IDE. На сегодняшний день существует плагин, который понимает такие методы, но позиция "нужен плагин, чтобы работать с фреймворком" слабая. Может лучше писать так, что бы код можно было поддерживать не привязываясь к IDE и плагинам? Понимаю, когда иначе никак не написать или вариант превосходит в своей полезности, но в данном случае это не так.
# Конфликт методов
И самая главная проблема - конфликт с "реальными" методами QueryBuilder-а. Например:
whereDate() whereTime() whereMonth() whereDay() whereYear() whereColumn() whereKey() whereExists() whereFullText() whereNot() whereHas() whereIn() whereBetween() whereJsonContains() whereNested() whereSub()
И это не полный список, который может дополняться с обновлениями фреймворка. Маловероятно, что в БД будут поля с именами has или in, но такая вероятность всегда есть. А, например, date, time, month, day, year, key, full_text встречаются достаточно часто. В данном случае будут вызваны методы фреймворка и чтобы сделать выборку по полю, придётся писать обычный where(), что делает код разностилевым и как следствие напрашивается логичный вариант - писать в одном стиле.
Я не буду отговаривать использовать "магический синтаксис", каждый делает выводы для себя сам, но не вижу ни одного плюса, чтобы отказаться от обычного where().
Тем не менее есть места, где "магический синтаксис" выглядит уместно и не доставляет проблем, например, в response:
1// regular syntax2response()->with('success', $message);3response()->with('errors', $errors);1// alternate magic syntax2response()->withSuccess($message);3response()->withErrors($errors);