АС
вам выше дали нормальный совет
Size: a a a
2020 March 15
АС
по интерфейсу резолвить сервис
АС
сервис внутри себя имеет фабричный метод
АС
и тот уже отдает нужный объект
АС
это тоже костыль, но менее корявый
АС
в фабричный метод лучше явно передать объект-пользователя
АС
разводите, блин, какую-то сраную магию со своим Тейлором
EG
Инжектите фабрику или локатор и из неё дёргайте $this->factory->forGuest() и forUser()
т.е. по DI пользователя лучше не гонять и не делать из DI factory
а из DI получить factory с зависимостью от контейнера и в зависимости от пользователя делаем:
а из DI получить factory с зависимостью от контейнера и в зависимости от пользователя делаем:
$interfaceClass = $factory->getClassByUser($user);
SM
$this->app->bind(Email::class, function ($app) {
return $app['request']->user()->getEmail();
});😂
АС
т.е. получается и проброс текущего пользователя через DI также допустимо, т.е.
или в данном случае лучше пробрасывать не пользователя, а \Illuminate\Auth\AuthManager
вопрос возникает постоятнно: "Как правильно пробросить в класс текущего пользователя?"
Варианты, что возникают:
1) проталкивать его через метод контроллера, как параметр для методов сервиса
2) притянуть через DI, но как, если конечно это приветствуется
$this->app->bind(Interface::class, function ($app) {
return new Class1($app['request']->user());
});или в данном случае лучше пробрасывать не пользователя, а \Illuminate\Auth\AuthManager
вопрос возникает постоятнно: "Как правильно пробросить в класс текущего пользователя?"
Варианты, что возникают:
1) проталкивать его через метод контроллера, как параметр для методов сервиса
2) притянуть через DI, но как, если конечно это приветствуется
как правильно?
получить сервис, занимающийся авторизацией
у него узнать - авторизован ли пользователь
получить сервис, занимающийся авторизацией
у него узнать - авторизован ли пользователь
DE
т.е. по DI пользователя лучше не гонять и не делать из DI factory
а из DI получить factory с зависимостью от контейнера и в зависимости от пользователя делаем:
а из DI получить factory с зависимостью от контейнера и в зависимости от пользователя делаем:
$interfaceClass = $factory->getClassByUser($user);
Либо в сам сервис инъектить Auth, либо доставать сервис из фабрики/локатора по user->id. Но никак не request.
АС
ну да
протечка запроса куда-то, кроме контроллера - вообще сильно-сильно плохо
протечка запроса куда-то, кроме контроллера - вообще сильно-сильно плохо
АС
просто адово плохо
DM
services:
App\MyService:
factory: ['@App\MyServiceFactory', createMyServiceFactory]
arguments: ['@security.context']
😉
2020 March 16
EG
services:
App\MyService:
factory: ['@App\MyServiceFactory', createMyServiceFactory]
arguments: ['@security.context']
😉
Symfony?
DM
Symfony?
угу
EG
// src/Service/ExampleService.phpв случае с Laravel это будет AuthManager, скорее всего
// ...
use Symfony\Component\Security\Core\Security;
class ExampleService
{
private $security;
public function __construct(Security $security)
{
// Avoid calling getUser() in the constructor: auth may not
// be complete yet. Instead, store the entire Security object.
$this->security = $security;
}
public function someMethod()
{
// returns User object or null if not authenticated
$user = $this->security->getUser();
}
}
EG
