Hours est une variable d'environnement, j'utiliserai ENV. Calme-toi, calme-toi, laisse-moi d'abord te dire quelque chose

Nous sommes toujours pressés et souhaitons développer le plus rapidement possible, et nous finissons souvent par adopter de vieilles habitudes et construire d'anciens logiciels, un élément que nous pouvons beaucoup améliorer est cette petite chose appelée environnement, comprenons un peu plus cela.

---

Tout d'abord, je voudrais montrer ici l'accent mis sur le concept de configurations pour Laravel, je ne me soucierai pas des standards restants, comme les ressources ou autres comme ça.

1 - Cherchons la connaissance !

Il y a quelque temps, j'ai entendu dire que je ne pouvais pas faire cette passe ENV avec mes codes fous, je me disais : wow
Le but est donc de comprendre les raisons, car de cette façon, nous pouvons prendre de meilleures décisions en tant qu'ingénieurs.

1.1 - Manière correcte ou point de vue ?

Alors allez petit futur maître, mettons une valeur dans une variable d'environnement pour pouvoir jouer, alors appelons ça :

Passons au premier point, excellente décision de placer cette configuration comme variable d'environnement, de cette façon vous rendez tout plus facile à gérer différents environnements (Production, approbation, Si vous en avez un ? ) et beaucoup plus sûr, car cette valeur Il ne sera pas exposé lorsque vous faites ce vilain git push dans votre référentiel (git/bitbucket), pouvez-vous imaginer que votre secret sur l'eau soit divulgué sur Internet, comme c'est triste.

Et pour récupérer cette valeur dans Laravel on peut utiliser la méthode env() ou aussi utiliser un autre package comme Support d'Illuminate (ça me rappelle les minions, je ne sais pas pourquoi ? )

env : Laravel Helper (qui utilise Env::get )
Env::get : classe Env du package Support Illuminate

Wow, c'est prêt, alors pourquoi continuer à inventer la mode ? La vérité est que ce n'est pas une bonne idée, je t'expliquerai pourquoi bientôt, reste avec moi.
Pour les différentes solutions, on peut citer les fichiers de configuration qui vont récupérer la valeur de l'environnement créé, donc le fichier de configuration est centralisé et allez, sérieusement ! bien mieux pour lire le code.

Dans cette situation spécifique vous pouvez déjà utiliser le fichier de configuration existant, appelé services.php, mais rien ne vous empêche de créer un fichier pour votre contexte spécifique.

Dans le chemin config/services.php

Et donc nous l'appellerons dans le code comme suit :

---

2 - Cool, mais pourquoi devrais-je utiliser des configurations pour récupérer des variables et pas seulement les récupérer directement ?

Je vais essayer de montrer quelques raisons :

2.1 - Performances accrues et meilleure utilisation des E/S

Pensez à la situation suivante : avez-vous des fichiers en production qui seront consultés à tout moment, effectuant des E/S considérables, ce qui augmentera les ressources de la machine et, selon la situation, des ralentissements du système ? (Et croyez-moi, jusqu'à ce que vous trouviez réellement le problème, vous passerez par des choses qui remettront en question toutes vos connaissances)

Quand on parle d'environnement de production, il est recommandé de mettre en cache vos beaux fichiers de configuration, avec Laravel vous pouvez utiliser artisan

php artisan config:cache

Cette belle commande prend tous les fichiers de configuration et leurs valeurs respectives et les compile en un seul fichier php, ce qui augmente les performances. Cela est dû au fait que les nombres IO sont réduits à 1

Curiosité : Lorsque vous utilisez cette commande, env() commence à renvoyer NULL car il désactive cette fonction. Donc si "Neida" et env() ont cessé de fonctionner, c'est tout.

Env() Effectuez des opérations d'E/S et elles sont coûteuses et lentes.

Il est préférable de faire cette opération une fois au début de l'application plutôt que de devoir effectuer l'opération à chaque fois que vous avez besoin d'un env.

2.2 - Organisation et standardisation de la meilleure façon possible

Vous pouvez facilement conserver tous vos paramètres comme vous le souhaitez. Vous pouvez mettre le nom du chien que vous voulez, créer un dossier et structurer tous les tableaux comme vous le souhaitez également, cela rendra la structure plus propre (à utiliser avec modération)
Par exemple :

Regardez cette clé :

et maintenant regardez cette clé :

À mon humble avis le 1er est bien meilleur.

Et en plus, vous pouvez avoir vos configurations similaires au bon endroit et centralisé sans avoir à les placer "au hasard" dans votre code, et j'aime beaucoup cette idée de structurer le tableau qui a tout son sens pour l'application.

Et les conseils pour les nouveaux développeurs sont beaucoup plus simples, car vous pouvez leur dire où et comment effectuer une nouvelle configuration.

Faites simple, faites la différence !

Merci pour tout jusqu'à présent.

Source :

Documentation de configuration de Laravel 11

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!