Может войдёшь?
Черновики Написать статью Профиль

«Хорошие практики»

Хорошие практики Laravel: соглашения об именовании

Best practices Хорошие практики

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

Что Правило Принято Не принято
Контроллер ед. ч. ArticleController ArticlesController
Маршруты мн. ч. articles/1 article/1
Имена маршрутов snake_case users.show_active users.show-active, show-active-users
Модель ед. ч. User Users
Отношения hasOne и belongsTo ед. ч. articleComment articleComments, article_comment
Все остальные отношения мн. ч. articleComments articleComment, article_comments
code_bright_anywhere

По первому пункту не согласен.

А где вообще кстати источник? со всем остальным согласен, за исключением контроллеров. Cледуя архитектуре REST, (которая безусловно является best practices для ларавел) мы рассматриваем сущности нашего приложения как Resources.
Ресурс — Articles
Ресурс — Books
Ресурс — Orders

и тд.

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

Хорошие практики Laravel: принцип единственной ответственности (Single Responsibility Principle)

Best practices Хорошие практики

Небольшое вступление

В мире Laravel существует очень серьезная, на мой взгляд, проблема. Laracasts, книги, видео туториалы, статьи и даже документация показывают нам использование плохих практик. Понятно, что делается это для популяризации фреймворка, снижая порог вхождения для новичков. Действительно, благодаря такому подходу, человек может написать работающее веб приложение при минимальных усилиях. И это хорошо. Плохо то, что разработчик продолжает писать низкокачественный код даже в сложных приложениях, в результате чего они порой становятся абсолютно неподдерживаемыми. Это значит, что любое изменение функционала в таком приложении занимает в разы, а иногда и в десятки раз больше времени разработчика и, соответственно, денег клиента. Также, эти…

VolCh

Правильное направление. Но полностью до SRP ещё далеко. Например, наличие в сервисе вызовов \request() говорит об отвественности сервиса парсить суперглобалы. Да ещё с помощью не очень явной зависимости.

← Назад | Дальше → Движется на Habravel