AS
Size: a a a
2020 March 13
В
Подскажите пожалуйста, зачем делать DI, записывать зависимость в св-во класса, если можно сделать фасад и обращаться к нему где хочешь?
ИС
Ну список фасадов не заканчивается на Auth
В
Есть несколько причин.
Одна из важных - еслм что-то не так с зависимостью ты узнаешь только в рантайме, используя фасады.
При внердении зависимости через конструктор или метод, ты узнаешь о проблеме уже на этапе создания класса или вызова метода.
Одна из важных - еслм что-то не так с зависимостью ты узнаешь только в рантайме, используя фасады.
При внердении зависимости через конструктор или метод, ты узнаешь о проблеме уже на этапе создания класса или вызова метода.
В
В статье описано подробно
ИС
Допустим не вижу ничего плохого, чтобы юзать такие фасады
В
Там описано, что может случиться и что в этом плохого или хорошего 🙂
ИС
Прочел статью
ИС
В статье разжевывается фасад Auth, аргументы валидные - результат выполнения методов этого фасада зависит от глобального контекста
ИС
но чем будет лучше прокинуть HashManager через DI в конструктор в сравнении с использованием фасада Hash - тут не описано
ИС
Готов выслушать аргументы :)
В
Auth там был как пример. Суть в том что фасад - это сервис локатор. От того что ты будешь использовать не Auth а Hash, ничего не измениться. Все аргументы остануться валидны
В
В том числе и тот, что я описал
ИС
Auth, Session, Request - такие фасады опасно использовать где-то в глубине кода, потому что результат зависит от глобального контекста
ИС
Есть несколько причин.
Одна из важных - еслм что-то не так с зависимостью ты узнаешь только в рантайме, используя фасады.
При внердении зависимости через конструктор или метод, ты узнаешь о проблеме уже на этапе создания класса или вызова метода.
Одна из важных - еслм что-то не так с зависимостью ты узнаешь только в рантайме, используя фасады.
При внердении зависимости через конструктор или метод, ты узнаешь о проблеме уже на этапе создания класса или вызова метода.
Покажи пример пожалуйста, не очень понял
ИС
public function handle(HashManager $hashManager) {
$hashedPassword = $hashManager->make($this->password);
}vs.
public function handle() {
$hashedPassword = Hash::make($this->password);
}ИС
чем первый вариант лучше?
В
public function handle(HashManager $hashManager) {if($request->has(‘some’)) {
$hashedPassword = $hashManager->make($this->password);} else {}
}public function handle(Request $request) {if($request->has(‘some’)) {
$hashedPassword = Hash::make($this->password);} else {}
}В
А если так
В
И там разобраны ещё аргументы:
There's a bigger chance of runtime errors.
The code is obfuscated to the outside.
It increases cognitive load.
There's a bigger chance of runtime errors.
The code is obfuscated to the outside.
It increases cognitive load.