Разработка отличных приложений должна быть общей целью, ради которой мы должны работать вместе!
Частью кодирования является знание лучших концепций и практик в технологиях, которые мы используем. В этой статье вы найдете несколько хороших практик, которые могут улучшить читабельность, ремонтопригодность и скорость вашего кода. Все следующие концепции исходят из того, что я узнал, прочитав Документацию Laravel и наблюдая за различными экспертами в области фреймворка и области, которые помогли мне создать хорошие и эффективные приложения, для которых я хочу поделиться с вами этими приемами.
1. 🥇 Принцип единой ответственности
Первый принцип SOLID предполагает, что классы и методы должны нести только одну ответственность, иначе мы рискуем получить сильно связанный код. В Laravel мы можем использовать IoC в классах или аксессорах в Eloquent для эффективной обработки.
Плохой:
Хороший:
2. 🆘 Контроллеры для маршрутов и Сервисы для бизнес-логики
Контроллеры должны быть напрямую связаны с потоком ответов/запросов, и каждый из методов внутри класса контроллера должен быть доступен только по маршруту. Более того, у контроллеров должна быть только одна обязанность, следовательно, общую бизнес-логику лучше разместить внутри Сервисов.
Плохой:
Хороший:
3. 🥠 Толстые модели, тощие контроллеры и толстые сервисы
Модели должны иметь всю логику, связанную с базой данных, чего можно добиться, просто используя области видимости, отношения, приведение типов и методы доступа. Контроллеры должны иметь поток запросов/ответов, таких как проверки, преобразования и ресурсы (которые вы также должны перенести в определенные классы). А у Сервисов должно быть все, что осталось; однако не все должно быть внутри одной службы, а разделять логику на разные службы в соответствии с SRP.
Плохой:
Хороший:
4. 🫙 Контейнер сервисов Laravel готов для нас
Laravel имеет встроенный сервисный контейнер для управления всеми зависимостями классов и эффективного выполнения внедрения зависимостей. Это действительно полезно, когда вы используете службы, внедряете модель в запрос или хотите использовать шаблон репозитория для лучшей масштабируемости и тестируемости.
Плохой:
Хороший:
5. 🏗️ Красноречие над необработанным SQL
Eloquent — это мощный объектно-реляционный преобразователь (ORM), который помогает разработчикам с легкостью писать красивый, читаемый и удобный для сопровождения код. Он имеет несколько встроенных функций, таких как области, отношения, обратимое удаление, события и т. д. Всякий раз, когда вам нужно получить доступ к БД, попробуйте использовать Eloquent, и только если это необходимо для конкретного случая, используйте необработанный SQL, но большинство время, когда вы найдете способ сделать это с помощью Eloquent.
Плохой:
Хороший:
Небольшое примечание: Eloquent может быть медленнее, чем Raw SQL, однако читабельность и ремонтопригодность, которые вы можете получить с помощью Eloquent, превосходят время отклика. Более того, вы всегда можете увеличить скорость вашего приложения с помощью Cache, так что на самом деле скорость Eloquent не будет иметь значения.
6. 🕵️♀️ Константы и языковые файлы вместо жестко заданного текста
Перемещение жестко закодированного текста в централизованные места повышает удобство сопровождения, удобочитаемость и масштабируемость кода. Например, если вы используете встроенную локализацию с самого начала проекта, вы гарантированно сможете перейти на другой язык в будущем.
Плохой:
Хороший:
7. 🎣 Получить данные .env из конфига вместо .env
Использование конфигурационных файлов позволяет вам лучше централизованно контролировать .env, который вы можете расширить, разделив задачи на разные файлы (так это делает Laravel). Более того, вы обычно кэшируете свои файлы в рабочей среде, что делает использование env() бесполезным, поскольку вместо фактического значения он возвращает null, однако config() по-прежнему возвращает правильное значение.
Плохой:
Хороший:
8. 🥋 Используйте работу для выполнения тяжелых задач
Тяжелые задачи блокируют выполнение кода и сокращают время отклика вашего сервера. Перемещение этих задач, потребляющих ресурсы ЦП, в очереди и диспетчеризация их через задания может улучшить взаимодействие с пользователем и повысить удобство использования вашего сервера.
Плохой:
Хороший:
Дополнительно — используйте Inertia + Vue вместо Blade
Я рекомендую использовать Vue вместо Blade, так как у вас есть более мощный контроль над вашими шаблонами, и если вы когда-нибудь захотите перейти от монолитного подхода к другой архитектуре, это будет проще, чем иметь все на Blade.
Inertia — это мощный мост между Laravel и Vue, который позволяет вам иметь монолитную архитектуру за счет рендеринга ответов Inertia (Vue Pages) вместо представлений Blades. Кроме того, Inertia имеет несколько встроенных функций, которые могут помочь вам быстрее разрабатывать приложение, например SSR, совместное использование данных, помощники по формам и т. д.
Наконец, как рекомендует сам Laravel, если вы хотите начать проект с уже готовым шаблоном, взгляните на Jetstream, вы можете выбрать между Livewire + Blade и Inertia + Vue, и у него есть классные функции для команд. управление, поддержка API, 2FA, регистрация, сеансы и многое другое.
Следите за новостями, чтобы увидеть больше подобных статей. Если вы хотите, чтобы я написал о чем-то, в частности, дайте мне знать в комментариях.
Я люблю учиться, поэтому я хотел бы прочитать ваше мнение и любые отзывы, чтобы продолжить мой путь обучения, пожалуйста, зайдите и оставьте комментарий!
Спасибо, что прочитали эту статью, давайте вместе создавать лучший мир! ❤
Следите за новостями и делитесь, если понравилось 😊
