В чем смысл использования фасада с IoC в Laravel

Я не понимаю смысла Facade, если вы собираетесь внедрить свой класс в контроллер как часть IoC.

Скажем, у меня есть нестандартный фасад под названием PostHelper. У меня есть 2 функции:

class PostHelper
{
    public function __construct() {} 

    public function all() {}

    public function get($id) {} 
}

Чтобы использовать этот помощник, с фасадами и без них (скажем, в вашем контроллере)

// Without Facade
$helper = new PostHelper();
return $helper->all();

// With Facade
return PostHelper::all();

Но это плохая практика, поскольку я не могу издеваться над PostHelper при его тестировании. Вместо этого я бы передал его конструктору своего контроллера:

class HomeController extends BaseController
{
    private $PostHelper;

    public function __construct(PostHelper $helper)
    {
        $this->PostHelper = $helper;
    }

    public function index()
    {
        return $this->PostHelper->all();
    } 
}

В конструкторе я мог бы просто использовать $this->PostHelper = new $helper(), если бы не создал фасад. В любом случае, я никогда не использую статичность фасада при использовании DI.

Так в чем же смысл использования фасада?


person Kousha    schedule 07.12.2014    source источник


Ответы (1)


Чтобы процитировать документацию:

Фасады предоставляют «статический» интерфейс для классов, доступных в контейнере IoC приложения. Laravel поставляется с множеством фасадов, и вы, вероятно, использовали их, даже не подозревая об этом! «Фасады» Laravel служат «статическими прокси» для базовых классов в контейнере IoC, обеспечивая преимущество краткого выразительного синтаксиса при сохранении большей тестируемости и гибкости, чем традиционные статические методы.

Это просто еще один способ использования внешних зависимостей без необходимости понимать внедрение зависимостей, как регистрировать и / или извлекать элементы с помощью контейнера IoC и т. Д. Это удобство, особенно для неопытных разработчиков или новичков. Laravel.

Если вы собираетесь внедрить свои зависимости (что вам следует), вам не нужны фасады.

Фактически вы можете имитировать фасады, но я бы по-прежнему практиковал обычную инъекцию зависимостей.

person Aken Roberts    schedule 08.12.2014
comment
Таким образом, в реальных приложениях Фасады НЕ полезны, так как вы всегда должны внедрять свои зависимости. - person Kousha; 08.12.2014
comment
Если вы хотите посмотреть на это таким образом, конечно. Я не подписываюсь на пуританские приложения PHP, которые являются мусором, если они не написаны в точном соответствии с этим менталитетом, потому что это мнение всегда будет различным среди разработчиков. Я рекомендую использовать DI в коде вашего домена, но предпочитаю использовать фасады в контроллерах из-за простоты разработки и того, что контроллеры зависят от платформы (обычно это не обязательно). - person Aken Roberts; 08.12.2014
comment
Если вы используете (настраиваемые) фасады в своем контроллере, как вы напишете для них модульный тест? Легко ли над ними издеваться? - person Kousha; 08.12.2014
comment
Я не заморачивался тестированием кода контроллера. Мои контроллеры обычно просто перенаправляют данные запроса службам на уровне домена, которые тестируются самостоятельно. Я не мог сказать вам, легко или нет издеваться над фасадами (хотя в документации создается впечатление, что это не имеет большого значения). - person Aken Roberts; 09.12.2014