Pomyślałem, że przyszłym odwiedzającym przyda się trochę wyjaśnienia tego, co się tutaj dzieje.
Illuminate\Http\Request
klasa
Illuminate\Http\Request
Klasa Laravela ma metodę o nazwie all
(w rzeczywistości all
metoda jest zdefiniowana w funkcji, której Request
używa klasa, zwana Illuminate\Http\Concerns\InteractsWithInput
). Podpis all
metody w momencie pisania wygląda następująco:
public function all($keys = null)
Ta metoda nie jest zdefiniowana jako static
i tak, gdy spróbujesz wywołać metodę w kontekście statycznym, tj. Illuminate\Http\Request::all()
Otrzymasz błąd wyświetlany w pytaniu OP. all
Metodą jest metoda instancji i dotyczy informacji, które są obecne w instancji Request
klasy, więc nazywając go w ten sposób nie ma sensu.
Fasady
Fasada w Laravel zapewnia programistom wygodny sposób uzyskiwania dostępu do obiektów w kontenerze IoC i wywoływania metod na tych obiektach. Deweloper może wywołać metodę „statycznie” na elewacji, jak na przykład Request::all()
, ale rzeczywiste wywołanie metody w rzeczywistym Illuminate\Http\Request
obiekcie nie jest statyczne.
Fasada działa jak proxy - odwołuje się do obiektu w kontenerze IoC i przekazuje wywołanie metody statycznej do tego obiektu (niestatycznie). Weźmy na przykład Illuminate\Support\Facades\Request
fasadę, tak to wygląda:
class Request extends Facade
{
protected static function getFacadeAccessor()
{
return 'request';
}
}
W gruncie rzeczy Illuminate\Support\Facades\Facade
klasa bazowa wykorzystuje trochę magii PHP, a mianowicie __callStatic
metodę:
- Nasłuchuj wywołania metody statycznej, w tym przypadku
all
bez parametrów
- Pobierz podstawowy obiekt z kontenera IoC przy użyciu klucza zwróconego przez
getFacadeAccessor
, w tym przypadku Illuminate\Http\Request
obiekt
- Dynamicznie wywołaj metodę, którą otrzymała statycznie na pobranym obiekcie, w tym przypadku
all
nazywana jest niestatycznie w instancji Illuminate\Http\Request
.
Dlatego, jak @patricus wskazał w swojej odpowiedzi powyżej, zmieniając instrukcję use
/ import tak, aby odnosiła się do fasady, błędu już nie ma, ponieważ jeśli chodzi o PHP, all
został poprawnie wywołany na instancji Illuminate\Http\Request
.
Aliasing
Aliasing to kolejna funkcja, którą Laravel zapewnia dla wygody. Działa poprzez efektywne tworzenie klas aliasów, które wskazują fasady w głównej przestrzeni nazw. Jeśli spojrzysz na swój config/app.php
plik, pod aliases
kluczem znajdziesz długą listę mapowań ciągów znaków na klasy elewacji. Na przykład:
'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 tworzy dla Ciebie te klasy aliasów, w oparciu o Twoją konfigurację, co pozwala na wykorzystanie klas dostępnych w głównej przestrzeni nazw (do których odnoszą się klucze łańcuchowe aliases
konfiguracji), tak jakbyś używał samej fasady:
use Request:
class YourController extends Controller
{
public function yourMethod()
{
$input = Request::all();
}
}
Uwaga na temat wstrzykiwania zależności
Chociaż Laravel nadal udostępnia fasady i aliasy, możliwe jest i zwykle zalecane jest skorzystanie z trasy wstrzykiwania zależności. Na przykład użycie iniekcji konstruktora, aby osiągnąć ten sam wynik:
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();
}
}
Takie podejście ma wiele zalet, ale moim osobistym zdaniem największym plusem wstrzykiwania zależności jest to, że ułatwia testowanie kodu. Deklarując zależności twoich klas jako argumenty konstruktora lub metody, bardzo łatwo staje się mockowanie tych zależności i testowanie jednostkowe klasy w izolacji.