Korektní využívání MVC a Managerů

Ano, muzes si vytvorit nejaky manager/facade/service nebo jak to nazves. Tam si injectnes DAO, pripadne EM. Ale dej si pozor, at ti nevznikne ohromna trida, ktera umi vse

precti si treba http://filip-prochazka.com/…o-dava-smysl

Napadla mě ještě jedna věc se kterou si nejsem jistý –

mějme tedy případ kdy registruji uživatele – v presenteru zavolám UserManager a jeho funkci register() a v register funkci budu volat MailManager ze kterého pošlu email a budu informovat o registraci. Je to takhle správně nebo mám volat MailManager v presenteru, pod UserManagerem?

Ripper: Posílání mailu je součástí business logiky, proto má být v modelu, v presenteru dle mě nemá co dělat. Vezmi si jednoduchý příklad, přijde požadavek, na to udělat mobilní verzi webu (jiné presentery), mobilní aplikaci (volání přes api) a budeš muset vždy volat dva managery najednou a zapomeneš na to a duplikujes kod. Proto je lepší mít UserManager->register – který zavolá mailmanager apod.

Pokud potrebuješ odkazy, tak je lepší použít jako service UrlGenerator

@Jiří Nápravník: Jasně, díky!

@matej21: Kdyby\Events používám, tedy plánuji to. Jenom jeden dotaz – pokud by subscriber zachytí událost onRegister, mám odesílat email přímo z něj, nebo si opět vytvořit nějaký EmailManager a v něm funkci na odeslání aktivačního e-mailu?

Omlouvám se za hloupé otázky, ale už dlouhou dobu v tom nemám jasno a chci v tom mít tedy pořádek.

@Ripper: idealni by to imho bylo RegistrationEmailSender, ktery by mel metodu ->send(User $user) a trida neco jako RegistrationEmailSenderInvoker, ktery by naslouchal na event a zavolal by na RegistrationEmailSender tu metodu send :) Ja bych asi sel cestou, ze by RegistrationEmailSender rovnou naslouchal na event.

@Jiří Nápravník: Ano, mas pravdu – muzes zkusit doplnek do phpstormu, ktery ti ty subscribery zobrazi

Ripper napsal(a):

@matej21: Kdyby\Events používám, tedy plánuji to. Jenom jeden dotaz – pokud by subscriber zachytí událost onRegister, mám odesílat email přímo z něj, nebo si opět vytvořit nějaký EmailManager a v něm funkci na odeslání aktivačního e-mailu?

Já bych si udělal classu UserMessenger, která by měla metodu třeba confirmRegistration($user), nebo notifyRegistration($user) a posílala by email/řadila ho do nějaké fronty na odeslání.

A listener

class RegistrationEmailListener extends Nette\Object implements Kdyby\Events\Subscriber
{
	private $messenger;

	public function __construct(UserMessenger $messenger) {
		$this->messenger = $messenger;
	}

	public function getSubscribedEvents() {
		return ['App\UserManager::onReqister'];
	}

	public function onReqister($manager, User $user) {
		$this->messenger->notifyRegistration($user);
	}

}

Jiří Nápravník napsal(a):

matej21: Můžeš mi prosím nějak laicky vysvětlit, kdy a hlavně proč je kdyby/events výhodné.

Eventy (obecně tedy subscriber/listener pattern) mají pomoct propojit modulární aplikaci.

Například když se ti vytvoří objednávka, zavoláš v metodě userConfirmedOrder($order) event

$this->onConfirm($this, $order);

Na to ti naslouchá listener a ten listener zavolá nějakou metodu na třídě co pracuje se skladem a ta vytvoří požadavky na nakoupení zboží. Třeba.

Nebo chceš

• přičítat kredity za objednávku? Listener
• máš časově omezenou soutěž která běží od do a počítá nějaké soutěžní body? přidáš další listener který bude před zavoláním metody $competition->addPoints($user, $order) zkontroluje že datum vytvoření objednávky spadá do času kdy beží soutěž
• chceš po dokončení objednávky přepočítat kde uživatel objednává a přidat mu restauraci do „oblíbených“? listener

Tady těch užití jsou mraky. A ano, máš pravdu, s eventy nevíš co se volá, protože nevíš co je na to navázané. Ale to je přesně ta pointa proč by to někdo dělal :) Je totiž velký rozdíl když mám věci co je potřeba udělat po odeslání objednávky v 10ti třidách kde každá se stará jenom o své a když všechno volám v jedné. SRP :)

Eventy se dají také použít i jako poor man's message queue :)

PS: víte že @Juznacz napsal pro Kdyby/Events rozšíření do PhpStormu?

Pokud se to logicky hodí k sobě, udělám jeden listener, který naslouchá na více událostí, pokud ne udělám jich více.

Na ty 3 věci bych nejspíše udělal listener jeden, hodně to záleží i od konkrétní aplikace, neumím se rozhodnou když neznám všechny souvislosti :)

Můžu trochu hloupý dotaz? Když si udělám nějaký UserListener a ten bude mít metody onRegister, onPswChange atd. jak potom tyto eventy odpálím? Zkoušel sem to navěsi na onSuccess metodu formu ale metoda se nezavolala.

Takže kdybych to aplikoval na příspěvek filipa tak v objektu: App\UserManager zavolám $this->onRegister() ? a kdyby.subscriber se o to postará?

No já to bral jen teoreticky, a jako službu jsem to uvažoval ;)