J'ai pensé qu'il serait utile que les futurs visiteurs fournissent une petite explication sur ce qui se passe ici.
La Illuminate\Http\Request
classe
La Illuminate\Http\Request
classe de Laravel a une méthode nommée all
(en fait la all
méthode est définie dans un trait que la Request
classe utilise, appelé Illuminate\Http\Concerns\InteractsWithInput
). La signature de la all
méthode au moment de la rédaction ressemble à ceci:
public function all($keys = null)
Cette méthode n'est pas définie comme static
et donc lorsque vous essayez d'appeler la méthode dans un contexte statique, c'est- Illuminate\Http\Request::all()
à- dire que vous obtiendrez l'erreur affichée dans la question de OP. La all
méthode est une méthode d'instance et traite les informations présentes dans une instance de la Request
classe, donc l'appeler de cette manière n'a aucun sens.
Façades
Une façade dans Laravel fournit aux développeurs un moyen pratique d'accéder aux objets du conteneur IoC et d'appeler des méthodes sur ces objets. Un développeur peut appeler une méthode "statiquement" sur une façade comme Request::all()
, mais l'appel de méthode réel sur l' objet réel Illuminate\Http\Request
n'est pas statique.
Une façade fonctionne comme un proxy - elle fait référence à un objet dans le conteneur IoC et transmet l'appel de méthode statique à cet objet (de manière non statique). Par exemple, prenez la Illuminate\Support\Facades\Request
façade, voici à quoi elle ressemble:
class Request extends Facade
{
protected static function getFacadeAccessor()
{
return 'request';
}
}
Sous le capot, la Illuminate\Support\Facades\Facade
classe de base utilise un peu de magie PHP, à savoir la __callStatic
méthode pour:
- Écoutez un appel de méthode statique, dans ce cas
all
sans paramètres
- Récupérez l'objet sous-jacent du conteneur IoC à l'aide de la clé renvoyée par
getFacadeAccessor
, dans ce cas, un Illuminate\Http\Request
objet
- Appelez dynamiquement la méthode qu'il a reçue de manière statique sur l'objet qu'il a récupéré, dans ce cas
all
est appelé de manière non statique sur une instance de Illuminate\Http\Request
.
C'est pourquoi, comme @patricus l'a souligné dans sa réponse ci-dessus, en changeant l' use
instruction / import pour faire référence à la façade, l'erreur n'est plus là, car en ce qui concerne PHP, all
a été correctement appelée sur une instance de Illuminate\Http\Request
.
Aliasing
L'aliasing est une autre fonctionnalité fournie par Laravel pour plus de commodité. Il fonctionne en créant efficacement des classes d'alias qui pointent vers des façades dans l'espace de noms racine. Si vous jetez un œil à votre config/app.php
fichier, sous la aliases
clé, vous trouverez une longue liste de mappages de chaînes aux classes de façade. Par exemple:
'aliases' => [
'App' => Illuminate\Support\Facades\App::class,
'Artisan' => Illuminate\Support\Facades\Artisan::class,
'Auth' => Illuminate\Support\Facades\Auth::class,
'Request' => Illuminate\Support\Facades\Request::class,
Laravel crée ces classes d'alias pour vous, en fonction de votre configuration et cela vous permet d'utiliser les classes disponibles dans l'espace de noms racine (comme indiqué par les clés de chaîne de la aliases
configuration) comme si vous utilisiez la façade elle-même:
use Request:
class YourController extends Controller
{
public function yourMethod()
{
$input = Request::all();
}
}
Une note sur l'injection de dépendances
Bien que les façades et l'aliasing soient toujours fournis à Laravel, il est possible et généralement encouragé de suivre la voie d'injection de dépendance. Par exemple, en utilisant l'injection de constructeur pour obtenir le même résultat:
use Illuminate\Http\Request;
class YourController extends Controller
{
protected $request;
public function __construct(Request $request)
{
$this->request = $request;
}
public function yourMethod()
{
$input = $this->request->all();
}
}
Il y a un certain nombre d'avantages à cette approche, mais à mon avis personnel, le plus grand avantage de l'injection de dépendances est qu'elle rend votre code plus facile à tester. En déclarant les dépendances de vos classes comme arguments de constructeur ou de méthode, il devient très facile de se moquer de ces dépendances et de tester individuellement votre classe.