Architektura aplikace: UI-Facades

Pro mě je dost matoucí to slovo logika. Když si řeknu význam slova logika co znám, tak mě nenapadá žádná spojitost s programováním. Mohl by mi někdo říct co přesně je tou logikou v programování myšleno? Existuje na to nějaká definice?

Zkouším ty fasády použít, ale narážím na pár problémů plynoucích z nepochopení, prosím tedy o rady.

1. Pokud používám fasády, znamená to, že by Presenter neměl přímo přistupovat k modelům (objekty typu Repository) když potřebuje data, ale vždy si o ně říct fasádě?
2. Je ve fasádách přípustné volání metod jako „related“ z NDB nebo by na to Entity měla mít konkrétní metodu (používám něco jako Fabik\Database).
3. Je špatně pokud fasáda implementuje \Nette\Security\IAuthenticator?

Editoval enumag (4. 2. 2013 18:34)

@enumag IMHO

1. o data žádáš fasádu
2. related přeskakuje fasádu a jde přímo do modelu / entity, ale hlavně je vázán na konkrétní mapper, takže related bych v něm nepoužíval a volal si patřičné metody dolů
3. je nějaký důvod, proč ji vázat na authenticator?

Na authenticator se ptám protože si nejsem jistý kam bych měl dát metodu na šifrování hesel, jestli do authenticatoru nebo jinam (kam?). Jedna fasáda tu metodu potřebuje taky protože ukládá uživatele…

@enumag To je přesně ten důvod, proč na to mít vlastní třídu/službu, kterou si ve fasádě zavoláš.

@enumag prostě mít authenticator s metodou na šifrování. Ve fasádě vytvořit instanci authenticatoru (popř. zavolat službu) a pak z něj volat kontrolu hesla…

@castamir: Opět mi potvrzuješ co jsem si myslel – a přesně to jsem od tebe potřeboval. ;-) Díky!

Ještě jedna věc. Mám formulář a mám model kam je chci uložit. Struktura dat ve formuláři ale moc neodpovídá struktuře dat v databázi takže nestačí jen předat modelu $form->getValues(). Moje otázka zní, kde by měla být konverzní logika z dat co vrátí formulář na data pro model?

1. V Presenteru? Ten by asi neměl moc znát strukturu databáze, vždyť ani nemá přímý přístup k modelu.
2. Ve třídě Facade? Tuto třídu vnímám jako vrstvu modelu, takže by asi neměla pracovat s komponentami ani vědět jak vypadá konkrétní formulář.
3. Každý formulář jako specializovanou třídu která bude řešit i ukládání? Co když je pro konkrétní formulář ukládání různé (jeden formulář který slouží pro vytváření i editaci)? Společné věci v abstraktním předkovi a každý specializovaný příklad (AddUserForm, EditUserForm) samostatně?
4. Jinde?

Editoval enumag (4. 2. 2013 22:40)

@enumag Opět. Presenter je „controler“, který umí spravovat komponenty. Mimo jiné i zpracovává signály včetně signálů od jeho komponent. Takže stačí v tomto, pro formulář, callbacku vzít údaje z formuláře (tedy pole) a zavolat si z fasády metodu pro uložení dat. Fasáda buď může sama rozhodnout, zda má vložit či aktualizovat záznam, nebo jí to lze vnutit a toto rozhodování nechat na výše zmíněném callbacku. Obě řešení jsou z mého pohledu korektní.

Fasáda by, aspoň podle mě, měla být schopna třídit data – nepotřebné hodnoty zahazovat atp..

Tak jsem zase přemýšlel nad „fasádama“ a není mi jasná jedna věc. Jakým způsobem by měla fasáda správně komunikovat s presenterem?

Příklad: Dejme tomu, že máme akci pro hromadný import osob, třeba z nějakého dlouhého textu, který musí fasáda rozparsovat a osoby uložit do DB.

1) Komunikace návratovou hodnotou

public function importFormSubmitted($form) {
	$result = $this->facade->import($form->values->persons);  // return TRUE|FALSE

	if ($result) {
		$this->flashMessage('Import OK');
		$this->redirect('this');
	} else {
		$this->flashMessahe('Import error');
	}
}

Toto se mi zdá na první pohled jako jednoduché a hezké řešení.

2) Komunikace vyjímkami

public function importFormSubmitted($form) {
	try {
		$this->facade->import($form->values->persons);
		$this->flashMessage('Import OK');
		$this->redirect('this');
	catch(PersonFacadeBadFormatException $e) {
		$this->flashMessahe('Import error');
	}
}

Tento způsob mi určitě při prvním čtení příspěvků chcete pochválit (ale dočtěte nejdřív na konec :-))

3) Komunikace návratovým polem s informacemi

public function importFormSubmitted($form) {
	$info = $this->facade->import($form->values->persons);

	$this->flashMessage($info['message'], $info['status']);
	$this->redirect('this');
}

Z tohoto způsobu mám prostě nějaký špatný pocit. Zdá se mi, že toto není ideální řešení, i když jeho zápis je nejkratší.

4) Komunikace referenčním parametrem s informacemi

public function importFormSubmitted($form) {
	$this->facade->import($form->values->persons, $info);  // informace o výsledku jsou předány do proměnné $info

	$this->flashMessage($info['message'], $info['status']);
	$this->redirect('this');
}

Viz možnost č. 3.

Takže pravděpodobně vyhrávají možnosti 1 a 2. V praxi je ale problém vždy složitější. Chtěl bych například v šabloně vypsat, které osoby se nepodařilo importovat (např už jsou v databázi, nebo mají špatný formát rodného čísla) – přičemž zbytek osob chci aby se importovali vpořádku. A najednou nám způsoby 1 a 2 nestačí, a musíme šáhnout po škaredém 3 či 4.

Jaký je tedy best-practise pro předávání zpráv Facade -> Presenter?

Ještě se dá použít:

$presenter = $this;
$this->facade->onImportSuccess[] = function($status, $message) use ($presenter) {
    $presenter->flashMessage($message, $status);
    $presenter->redirect('this');
}

...

public function importFormSubmitted($form) {
    $this->facade->import($form->values->persons);
}

i když to na první pohled nevypadá tak elegantně.

Výhoda je, že tam můžeš zaregistrovat i další callbacky, nejen presenter (odeslání mailu, uložení do logu, …). A asi by se použily obecnější parametry než $status a $message – ty jsou šité na míru právě presenteru.

Edit: Aha, tady se bavíme o UI fasádách, tam bude ten callback téměř vždy jen jeden. Tohle se vyplatí spíš u klasických services.

Editoval mkoubik (26. 3. 2013 8:55)

ja nevidim nic zle na sposobe 3. ked komunikujes s nejakym api tiez dostavas ako odpoved nejake pole popripade objekt. ak sa ti nepaci pole mozes vytvorit objekt Response, ktory moze obsahovat napr status, zoznam nepodarenych importov atd

No v pripade ako pise @nanuqcz, ze chce vypisat zaznamy ktore neslo importovat by bol dobry este medzikrok ktory data overi.

Nepride mi ako dobry napad urobit to ako pise. Vrazim tam nieco, vsak sa nieco stane a potom budem lustit ktore osoby mam este dodat :-). Pozor ale tie ktore uz tam su musim zmazat!

Siel by som cestou:

1. Upload csv (.xls…)
2. Check dat a vypis toho co je zle (user si to moze upravit priamo v editore)
3. Ak check prechadza tak data (mozem ich mat niekde ulozene ak check presiel) importnem.

Co sa tyka tych 4 postupov. Osobne som za vynimky. Nie som si isty ale mozno by slo tie data ktore suvisia s tou vynimkou narvat ako 3. parameter danej vynimky ;-). Tym padom sa data suvisiace s vynimkou prenesu tam kam ich „potrebujes“.

Vynimky aj z dovodu, ze ked zacnes pouzivat Eventy (emaily, logy, …) tak iny sposob ani nepripada (samozrejme neviem vsetko :-)) do uvahy.

Vyjímky bych použil v případě, že se nenaimportuje nic, prostě došlo k chybě.
Pokud potřebuješ vrátit log o neimportovancýh uživatelech, přikláněl bych se k struturovanému poli, lépe však k Resul objektu. Logicky, obyč true/false ti nestačí a možnost 4 odporuje logickému chápání vstup/výstup.