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

Прежде всего, я хотел бы показать здесь фокус на концепции конфигураций для laravel, я не буду беспокоиться об остальных шаблонах, таких как ресурсы и тому подобное.

1 - Давайте искать знания!

Некоторое время назад я услышал, что не могу выполнить этот проход ENV в своих сумасшедших кодах, я подумал; ух ты
Итак, цель состоит в том, чтобы понять причины, потому что таким образом мы, как инженеры, сможем принимать более правильные решения.

1.1 - Правильный путь или точка зрения?

Итак, маленький будущий мастер, давайте поместим значение в переменную среды, чтобы мы могли поиграть, поэтому назовем ее:

Давайте перейдем к первому пункту, отличное решение поместить эту конфигурацию в качестве переменной среды, таким образом вы упростите управление различными средами (Производство, утверждение, если она у вас есть?) и намного безопаснее, потому что это значение не будет раскрыт, когда вы сделаете этот непослушный git push в своем репозитории (git/bitbucket), можете ли вы представить, что ваш секрет воды утечет в Интернет, как грустно

И чтобы получить это значение в Laravel, мы можем использовать метод env() или также использовать другой пакет, например Support от Illuminate (он напоминает мне миньонов, я не знаю почему? )

env: Laravel Helper (который использует Env::get )
Env::get: класс Env из пакета Support Illuminate

Ух ты, все готово, так зачем продолжать изобретать моду? Правда в том, что это не очень хорошая идея, скоро я объясню почему, оставайся со мной.
В качестве другого решения мы можем упомянуть файлы конфигурации, которые будут получать значение созданной среды, поэтому файл конфигурации централизован, и давайте серьезно! гораздо лучше для чтения кода.

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

По пути config/services.php

И поэтому в коде мы будем называть это так:

2 — Круто, но почему я должен использовать конфигурации для извлечения переменных, а не просто получать их напрямую?

Я постараюсь показать некоторые причины:

2.1 – Повышение производительности и лучшее использование ввода-вывода

Подумайте о следующей ситуации: есть ли у вас в производстве файлы, к которым будет осуществляться постоянный доступ, выполняя значительный объем операций ввода-вывода, что приведет к увеличению ресурсов компьютера и, в зависимости от ситуации, к замедлению работы системы? (И поверьте мне, пока вы действительно не найдете проблему, вы будете проходить через вещи, которые поставят под сомнение все ваши знания)

Когда мы говорим о производственной среде, рекомендуется кэшировать ваши красивые файлы конфигурации, а с Laravel вы можете использовать artisan

php artisan config:cache

Эта красивая команда берет все файлы конфигурации и соответствующие им значения и компилирует их в один php-файл, что повышает производительность. Это связано с тем, что номера ввода-вывода уменьшены до 1

Любопытство: Когда вы используете эту команду, env() начинает возвращать NULL, поскольку отключает эту функцию. Так что если от "Нейды" env() ваш перестал работать, то всё.

Env() Выполнение операций ввода-вывода является дорогостоящим и медленным.

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

2.2 - Наилучшая организация и стандартизация

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

Посмотрите на этот ключ:

а теперь посмотрите на этот ключ:

По моему скромному мнению, первая намного лучше.

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

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

Будьте проще, будьте отличительной чертой!

Спасибо за все.

Источник:

Конфигурация документации Laravel 11