Laravel: внедрение зависимостей против фасадов?

Laravel теперь поддерживает те же функции внедрения для методов классов (не только конструкторов), связанных с маршрутами, таких как контроллеры и промежуточное ПО.

Вы можете предотвратить ненужные инъекции, вводя только те методы, в которых зависимость уникальна, возможно, оставив более общие зависимости в конструкторе:

class MyController extends BaseController 
{
    public function __construct( Input $input, Session $session, Redirect $redirect ) {
        $this->input = $input;
        $this->session = $session;
        $this->redirect = $redirect;
    }

    public function foobar ( User $user, Bookmark $bookmark ) {
        $user_id = $this->input->get('bar');
        ...
        $this->session->get('someInfo');
        ...
        return $this->redirect->to('/');
    }
    ...
}

Что касается того, следует ли вам делать это таким образом, решать вам - принудительное отображение всех зависимостей в определениях методов кажется мне более понятным и более простым для модульного тестирования.

Элегантно и полезно внедрять определенные классы, такие как Request. На мой взгляд, они должны быть указаны в методах контроллера там, где они необходимы, поскольку затем они логически связаны с реализацией метода. Пока что отлично.

Я считаю, что проблемными являются два фасада - приложение и журнал. Ни тот, ни другой логически не связаны с контроллером или его действиями. Приложение и журнал не являются входными данными ни в каком контексте. Поскольку приложение и журнал являются служебными классами, они также имеют отношение к службам и репозиториям, и становится совершенно неприятно, если вы вводите подсказку в контроллерах, а затем передаете их в качестве параметров конструктора или метода вашим классам поддержки.

Дополнительная проблема заключается в том, что фасад приложения не реализует интерфейс Illuminate \ Contracts \ Auth \ Guard, который он передает через прокси, поэтому моя IDE загорается с предупреждениями, поскольку статический анализ невозможен.

Поэтому для согласованности и общего разделения проблем я бы создал экземпляры приложения и журнала в конструкторе или методе, в зависимости от того, насколько широко они используются в классе. Чтобы моя IDE была довольна, я создал следующий класс, чтобы предоставить мне правильно типизированный экземпляр, где бы он ни был:

<?php namespace App\Components;

use Illuminate\Contracts\Auth\Guard;
use Psr\Log\LoggerInterface;

/**
 * Get the underlying object instances of facades from the container.
 */
class AppGlobal
{
    /**
     * Returns the global logger instance.
     *
     * @return LoggerInterface
     */
    public static function log()
    {
        return app('log');
    }

    /**
     * Returns the global auth instance, which internally proxies a guard.
     *
     * @return Guard
     */
    public static function auth()
    {
        return app('auth');
    }

}

Если вам нужен объект со свойствами - вставьте его как инъекцию (например, Input, Session ...), в противном случае, если вы не храните никаких данных в объекте и довольно довольны использованием класса, чем используйте фасады (например, Log :: ..., Перенаправить :: ...).

Laravel заменил многие фасады, например, помощниками.

use Auth;

и

Auth::user()

сейчас просто

auth()->user()

это делает работу проще и аккуратнее (также предотвращает ошибки)

Я бы посоветовал использовать помощники, где это возможно, и если помощник не существует, использовать фасад, потому что его легче смоделировать, чем внедренный экземпляр.