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

Хорошие практики 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
Таблица мн. ч. article_comments article_comment, articleComments
Pivot таблица имена моделей в алфавитном порядке в ед. ч. article_user user_article, articles_users
Столбец в таблице snake_case без имени модели meta_title MetaTitle; article_meta_title
Внешний ключ имя модели ед. ч. и _id article_id ArticleId, id_article, articles_id
Первичный ключ - id custom_id
Миграция - 2017_01_01_000000_create_articles_table 2017_01_01_000000_articles
Метод camelCase getAll get_all
Метод в контроллере ресурсов таблица store saveArticle
Метод в тесте camelCase testGuestCannotSeeArticle test_guest_cannot_see_article
Переменные camelCase $articlesWithAuthor $articles_with_author
Коллекция описательное, мн. ч. $activeUsers = User::active()->get() $active, $data
Объект описательное, ед. ч. $activeUser = User::active()->first() $users, $obj
Индексы в конфиге и языковых файлах snake_case articles_enabled ArticlesEnabled; articles-enabled
Представление snake_case show_filtered.blade.php showFiltered.blade.php, show-filtered.blade.php
Конфигурационный файл snake_case google_calendar.php googleCalendar.php, google-calendar.php
Контракт (интерфейс) прилагательное или существительное Authenticatable AuthenticationInterface, IAuthentication
Трейт прилагательное Notifiable NotificationTrait

Если у вас есть дополнения к таблице, пишите их в комментариях или в подфоруме о хороших практиках.

Хотите увидеть больше статей на тему хороших практик? Поддержите проект поставив звезду в репозитории хороших практик Laravel. Это показывает есть ли интерес к этой теме, а также здорово мотивирует автора на написание других полезных материалов.

Как вы считаете, полезен ли этот материал? Да Нет

Комментарии (10)

skey

Здраствуйте, не соглашусь с первым пунктом. Из практити вышло, что лучше создавать ArticlesController,
так как когда мы используем Pivot Tables, то тогда намного лучше с ними работать.
И в случае ArticlesController легко будет этим всем управлять, каждый роут будет отображать название таблицы.

Ellrion

Что то аргумент не понятен. Причем тут пивот таблицы и имя контроллера? Можете пояснить, пожалуйста

skey

Если ктонибудь работает роутингом на Pivot таблицах, нп: attribute_product, то ему будет проще называть контроллер так же, как и таблицу.
Будет:
attrbiute_product, AttributeProductController, attribute_product/{id}
А в случае с articles:
articles, ArticlesController, articles/{id}.

То что придлагает автор говорит нам менять название контролера на ед. ч. Но зачем? Если все можна сделать очень просто.
Ну и если взять его пример то как быть с attribute_product.

fomvasss

Еще можно добавить именование таблиц для полиморфических отношений «многие ко многим», например таблица для связи тегов с сущностямы: taggables

А вот в отличии от этой таблицы, роуты я называю в ед. ч.

AlexeyMezenin

Спасибо, добавлю именование таблиц для полиморфических отношений.

shasoft

А что по названию пакетов? Делаю пакет для работы с ресурсами. Называть его vender/asset или vendor/assets?

AlexeyMezenin

Не встречал обсуждений этого вопроса. Думаю, что лучше в форуме задать этот вопрос.

shasoft

Задал на форуме вопрос. Ссылку ставлю чтобы если кто заинтересуется знал где искать
https://laravel.ru/forum/viewtopic.php?pid=15500

code_bright_anywhere

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

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

и тд.

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

VolCh

Сущность — ресурс, правильно. Например, ресурс /articles/1 представляет собой сущность класса Article с идентификатором 1. Но кроме ресурсов, представляющих сущности, есть ресурсы, представляющие коллекции сущностей, например /articles. По хорошему вообще надо разделить контроллеры на ArticleController и ArticleCollectiontController, где первый управляет представлением сущности, а второй списка сущностей. Но обычно во втором тогда будет только пара методов для GET и POST, вот и примешивают их к первому.

Написать комментарий

Разметка: ? ?

Авторизуйся, чтобы прокомментировать.