Laravel по-русски
Эта статья - попытка собрать в одном месте все существующие на данный момент соглашения об именовании, гласно или негласно принятые сообществом 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. Это показывает есть ли интерес к этой теме, а также здорово мотивирует автора на написание других полезных материалов.
Комментарии (13)
Здраствуйте, не соглашусь с первым пунктом. Из практити вышло, что лучше создавать ArticlesController,
так как когда мы используем Pivot Tables, то тогда намного лучше с ними работать.
И в случае ArticlesController легко будет этим всем управлять, каждый роут будет отображать название таблицы.
Что то аргумент не понятен. Причем тут пивот таблицы и имя контроллера? Можете пояснить, пожалуйста
Если ктонибудь работает роутингом на Pivot таблицах, нп: attribute_product, то ему будет проще называть контроллер так же, как и таблицу.
Будет:
attrbiute_product, AttributeProductController, attribute_product/{id}
А в случае с articles:
articles, ArticlesController, articles/{id}.
То что придлагает автор говорит нам менять название контролера на ед. ч. Но зачем? Если все можна сделать очень просто.
Ну и если взять его пример то как быть с attribute_product.
Еще можно добавить именование таблиц для полиморфических отношений «многие ко многим», например таблица для связи тегов с сущностямы: taggables
А вот в отличии от этой таблицы, роуты я называю в ед. ч.
Спасибо, добавлю именование таблиц для полиморфических отношений.
А что по названию пакетов? Делаю пакет для работы с ресурсами. Называть его vender/asset или vendor/assets?
Не встречал обсуждений этого вопроса. Думаю, что лучше в форуме задать этот вопрос.
Задал на форуме вопрос. Ссылку ставлю чтобы если кто заинтересуется знал где искать
https://laravel.ru/forum/viewtopic.php?pid=15500
По первому пункту не согласен.
А где вообще кстати источник? со всем остальным согласен, за исключением контроллеров. Cледуя архитектуре REST, (которая безусловно является best practices для ларавел) мы рассматриваем сущности нашего приложения как Resources.
Ресурс — Articles
Ресурс — Books
Ресурс — Orders
и тд.
Если попытаться обработать контроллер с точки зрения восприятия его человеческой логики, и, рассматривая сущности как ресурсы, то в случае именования контроллера как ArticleController, и попытке вызвать метод индекс, мы говорим, мы хотим получить список ресурсов — множественное число. ну и вообще, если рассматривать контроллер как инструмент работы с ресурсами, то просится множественное число. В единственном числе вообще не встречал ни разу)
Сущность — ресурс, правильно. Например, ресурс /articles/1 представляет собой сущность класса Article с идентификатором 1. Но кроме ресурсов, представляющих сущности, есть ресурсы, представляющие коллекции сущностей, например /articles. По хорошему вообще надо разделить контроллеры на ArticleController и ArticleCollectiontController, где первый управляет представлением сущности, а второй списка сущностей. Но обычно во втором тогда будет только пара методов для GET и POST, вот и примешивают их к первому.
не понял, почему свойства класса или переменные в camelCase?
Как может фреймворк рекомендовать именование таблиц БД?
А если уже существует БД именование в которой отличается от указанного выше,
то нарушать best practices?
Как называть таблицы и поля не может рекомендовать PHP-фреймворк.
Это сомнительно! Однако название очень кричащее и много на себя берущее!
Так это в целом хорошая практика для БД. Здесь просто напоминают, что лучше так.