Я подумал, что для будущих посетителей будет полезно дать небольшое объяснение того, что здесь происходит.
Illuminate\Http\Request
класс
У Illuminate\Http\Request
класса Laravel есть метод с именем all
(на самом деле all
метод определяется в трейте, который Request
использует класс, называемом Illuminate\Http\Concerns\InteractsWithInput
). Сигнатура all
метода на момент написания выглядит так:
public function all($keys = null)
Этот метод не определен как static
и поэтому, когда вы пытаетесь вызвать метод в статическом контексте, т.е. Illuminate\Http\Request::all()
вы получите сообщение об ошибке, отображаемое в вопросе OP. all
Метод является методом экземпляра и имеет дело с информацией, которая присутствует в экземпляре Request
класса, поэтому называть его таким образом , не имеет смысла.
Фасады
Фасад в Laravel предоставляет разработчикам удобный способ доступа к объектам в контейнере IoC и вызова методов для этих объектов. Разработчик может вызвать метод «статически» на фасаде, например Request::all()
, на фасаде , но фактический вызов метода на реальном Illuminate\Http\Request
объекте не является статическим.
Фасад работает как прокси - он обращается к объекту в контейнере IoC и передает вызов статического метода этому объекту (нестатически). Например, возьмем Illuminate\Support\Facades\Request
фасад, вот как он выглядит:
class Request extends Facade
{
protected static function getFacadeAccessor()
{
return 'request';
}
}
Под капотом базовый Illuminate\Support\Facades\Facade
класс использует некоторую магию PHP, а именно __callStatic
метод:
- Слушайте вызов статического метода, в данном случае
all
без параметров
- Возьмите базовый объект из контейнера IoC, используя ключ, возвращаемый
getFacadeAccessor
, в данном случае Illuminate\Http\Request
объект
- Динамически вызывать метод, который он получил статически для полученного объекта, в этом случае
all
вызывается нестатически для экземпляра Illuminate\Http\Request
.
Вот почему, как указал @patricus в своем ответе выше, изменив use
оператор / import для ссылки на фасад, ошибки больше нет, потому что, что касается PHP, all
был правильно вызван для экземпляра Illuminate\Http\Request
.
Сглаживание
Псевдонимы - еще одна функция, которую Laravel предоставляет для удобства. Он работает, эффективно создавая классы псевдонимов, которые указывают на фасады в корневом пространстве имен. Если вы посмотрите на свой config/app.php
файл, под aliases
ключом вы найдете длинный список сопоставлений строк с классами фасадов. Например:
'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 создает для вас эти псевдонимы классов на основе вашей конфигурации, и это позволяет вам использовать классы, доступные в корневом пространстве имен (на что указывают строковые ключи aliases
конфигурации), как если бы вы использовали сам фасад:
use Request:
class YourController extends Controller
{
public function yourMethod()
{
$input = Request::all();
}
}
Замечание о внедрении зависимостей
Хотя фасады и псевдонимы по-прежнему предусмотрены в Laravel, можно и обычно рекомендуется идти по пути внедрения зависимостей. Например, использование внедрения конструктора для достижения того же результата:
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();
}
}
У этого подхода есть ряд преимуществ, но, по моему личному мнению, самым большим преимуществом внедрения зависимостей является то, что он упрощает тестирование кода. Объявляя зависимости ваших классов в качестве аргументов конструктора или метода, становится очень легко имитировать эти зависимости и изолированно тестировать свой класс.