Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
>Переменные $articlesWithAuthor
Это сначала articles тк сначала их берем в запросе. Множественное число тк коллекция. Для каждого артикла один автор и потому он единственный. Те все исходит из здравого смысла и содержимого переменной.
"Контракт (интерфейс): прилагательное или существительное Authenticatable"
То есть СhangePasswordContract ChangePasswordService те включающие контракт сервис названия плохие...
Сервис и репозиторий как называть я бы тоже внес в таблицу.
А сокращение Pass вместо Password Trans вместо Transaction плохо?
Не в сети
Сервис и репозиторий как называть я бы тоже внес в таблицу.
Таких соглашений я не видел, но если наткнусь, добавлю.
То есть СhangePasswordContract ChangePasswordService те включающие контракт сервис названия плохие...
Мне кажется, что обозначить сервис в названии нужно. А контракт и так видно в любой IDE, что это интерфейс.
А сокращение Pass вместо Password Trans вместо Transaction плохо?
Иногда нормально сокращать, но лучше на буквах не экономить. Например, Auth - это authentication или authorization? Pass - это password или pass? Trans - это transaction, transfer, transformer или translation?
Не в сети
А имеет ли смысл держать контракты, трейты, сервисы, интерфейсы каждые в своей папке? Или только часть этих классов заслуживает отдельной папки? должны ли все они так или иначе лежат в папке Models или типа того?
Не в сети
А имеет ли смысл держать контракты, трейты, сервисы, интерфейсы каждые в своей папке?
Соглашений нет, кто как делает. Да и от ситуации зависит.
Не в сети
Но все же наверное есть классы которые вообще дурной тон класть в общую папку с другими, например Нотификации или Провайдеры там же сама Ларавель папки создает...
В тоже время по мне так лучше на папки все побить. Но в то же время в конце класса не дописывать Service Helper Interface итд
Не в сети
В тоже время по мне так лучше на папки все побить. Но в то же время в конце класса не дописывать Service Helper Interface итд
Сервисы я в отдельную папку кладу и дописываю слово Service, потому что тогда в коде видно, что именно за класс. Интерфейсы и трейты я обычно кладу туда, где находятся остальные классы фичи/модуля.
Не в сети
А имеет ли смысл класть все контроллеры/вьюхи которые относятся к ЛК пользователя и к админке в отдельные папки home admin я так сделал, но теперь кажется что толку то нет..
Не в сети
А имеет ли смысл класть все контроллеры/вьюхи которые относятся к ЛК пользователя и к админке в отдельные папки
Я так и делаю. Например, шаблоны для админки в resources/views/admin, контроллеры в app/Http/Controllers/Admin и т.д.
Не в сети
Да и у меня также значит оставлю..
Не в сети
Страницы 1