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

AlexeyMezenin +484

Вступил в наши ряды: 3 марта 2016

Замечен в последний раз: 20 марта 2020

Оставил на форуме: 783 сообщения и 11 тем

Последнее сообщение: 4 марта 2018

Вы сможете отправить письмо, если войдёте

Статьи (3)

Хорошие практики 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

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

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

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

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

Словарь терминов Laravel

laravel термины

Очень часто случаются ситуации, когда разработчики не сразу понимают друг друга. Общаясь на форуме, они называют одни и те же вещи по-разному. В ход идут различные переводы одних и тех же терминов, слэнг и рунглиш, режущие слух.

Мне кажется, я нашел выход: можно пользоваться словарем, поддерживаемым и регулярно обновляемым всем сообществом. Внести изменения можно здесь, с помощью коммита, а обсудить наилучший вариант перевода того или иного термина можно в данной ветке. Словарь будет регулярно обновляться, поэтому вы смело можете внести эту страницу в закладки.

Неплохой, на мой взгляд, альтернативой данному словарю может быть использование оригинальных терминов на английском…

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

AlexeyMezenin

Ты не совсем понимаешь что такое политики, поэтому рекомендую начать знакомство с ними с документации.

Почему следует использовать политики вместо сторонних решений? Потому что это стандартный инструмент фреймворка и стоимость разработки и поддержки при этом на порядок ниже.

Ну и один камень в огород overkill решений вроде Entrust - это проблемы с быстродействием (N+1, например), баги и более сложная (часто нечитаемая) итоговая логика. Эти проблемы возникают из-за неумения новичков обращаться с пакетами и из-за непонимания как именно они работают "под капотом". А именно новички, прочитав очередной туториал, начинают использовать этот пакет в каждом своем приложении, даже там, где есть всего две роли - пользователь и админ и нет необходимости динамически назначать разрешения.

AlexeyMezenin

Данные — это БД в большинстве случаев.

AlexeyMezenin

Все, что связано с данными, лучше хранить в моделях. Если есть преобразование данных, тогда Eloquent Resource классы (в 5.5+), либо отедльные классы для преобразования.

Все остальное хранить лучше в классах с бизнес логикой и сервисах, в зависимости от архитектуры. На счет структуры папок, я использую стандартную. Сервис классы в app\Services, модели в app\.

AlexeyMezenin

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

AlexeyMezenin

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

AlexeyMezenin

Учитывая то, что практически все реальные приложения пишутся игнорируя описанное в статье, не такие уж и «истины».

AlexeyMezenin

Спасибо, исправил.

AlexeyMezenin

Понимаю, тоже часто с подобным отношением сталкиваюсь. Не все понимают важность использования хороших практик для создания поддерживаемых приложений. Если есть дополнения к практикам в репозитории, буду рад о них услышать. )

AlexeyMezenin

Спасибо за идею, если будет время, займусь. А пока, вот такой вот репозиторий есть.

AlexeyMezenin

Я всерьез думал об этом когда ко мне обратилась менеджер Packt с предложением написать самоучитель по Laravel. Много думал и пришел к выводу, что писать очередную книгу смысла нет, а написать книгу для новичков и сразу по ходу объяснять «как правильно делать» ну очень сложно. Человек так устроен, что он не может впитать слишком много информации за короткий промежуток времени, поэтому лучше всего начать обучение с обычной книги для новичков или видеокастов, а уже потом расти. Для меня этот продход работает.

А переучиться не так сложно. Все мы когда-то писали полную жесть и будущие мы будут считать, что сейчас мы тоже пишем убогий код. Мы все время растем, это нормально.

AlexeyMezenin

Спасибо, точки убрал.

Не уверен на счет размазывания кода, не думаю, что видел такое в приложениях. Наоборот, весь код обычно в контроллерах. В моем примере присутствует размазывание?

AlexeyMezenin

Спасибо за дополнение.

Переиспользовать метод можно, ведь в любом случае этот метод зависит от данных в объекте Request. Тестируется это тоже отлично. Плюс же заключается в том, что мы не передает множество данных, а просто внедряем Request. Если бы мы работали с моделью или другими классами, там да, нужно передавать непосредственно данные (массив, создаваемый $request->all()), хотя многие передают объект Request.

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

Если у тебя есть дополнения к описанным практикам Laravel, буду благодарен, если поделишься ими здесь

AlexeyMezenin

В контрололерах — всю логику.

Это не MVC.

И ты не ответил, ты в контроллере данные будешь итерировать? Т.е. ты в контроллере будешь лепить что-то вроде:

foreach ($page->children() as $child) {
      $a .= '<li>'.$child->title.'</li>';
}
AlexeyMezenin

Проблем с пробелами «почти нет», много использовал в реальном проекте (не только с запятой). Где-то помню проблема была. Решил тем, что в span обернул. За пример с CSS спасибо.

AlexeyMezenin

Кстати, хочу поделиться очень полезным сниппетом, показывающим насколько $loop - полезная переменная. Перечисление данных массива, разделенных запятой, когда запятую в конце ставить не нужно:

@foreach ($arrayOrCollection as $value)
    {{ $loop->first ? '' : ', ' }}
    <span class="nice">{{ $value->first_name }}</span>
@endforeach
AlexeyMezenin

Контроллер имеет минимум логики, от вытягивает данные из модели и передает в представление. Представление — это не только оформление. Перечислять (итерировать) данные ты в контроллере будешь?