Pomyślałem, że przyszłym odwiedzającym przyda się trochę wyjaśnienia tego, co się tutaj dzieje.
Illuminate\Http\Requestklasa
Illuminate\Http\RequestKlasa Laravela ma metodę o nazwie all(w rzeczywistości allmetoda jest zdefiniowana w funkcji, której Requestużywa klasa, zwana Illuminate\Http\Concerns\InteractsWithInput). Podpis allmetody w momencie pisania wygląda następująco:
public function all($keys = null)
Ta metoda nie jest zdefiniowana jako statici tak, gdy spróbujesz wywołać metodę w kontekście statycznym, tj. Illuminate\Http\Request::all()Otrzymasz błąd wyświetlany w pytaniu OP. allMetodą jest metoda instancji i dotyczy informacji, które są obecne w instancji Requestklasy, 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\Requestfasadę, tak to wygląda:
class Request extends Facade
{
protected static function getFacadeAccessor()
{
return 'request';
}
}
W gruncie rzeczy Illuminate\Support\Facades\Facadeklasa bazowa wykorzystuje trochę magii PHP, a mianowicie __callStaticmetodę:
- Nasłuchuj wywołania metody statycznej, w tym przypadku
allbez parametrów
- Pobierz podstawowy obiekt z kontenera IoC przy użyciu klucza zwróconego przez
getFacadeAccessor, w tym przypadku Illuminate\Http\Requestobiekt
- Dynamicznie wywołaj metodę, którą otrzymała statycznie na pobranym obiekcie, w tym przypadku
allnazywana 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, allzostał 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.phpplik, pod aliaseskluczem 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 aliaseskonfiguracji), 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.