Vlákno názorů k článku
Nette Framework: MVC & MVP

Muj problem s MVC pristupem je ten, ze casto je velmi spatna podpora aktivni komunikace ze strany modelu k view. Zni to jako paradox, ale proste se jedna o klasicky pripad, kdy treba mam v GUI tabulku s daty (ted mam na mysli klasickou, ne-webovskou aplikaci) a model je navazany at uz na databazi nebo treba zobrazuje obsah slozky. Treba ve Swingu je docela porod, aby model notifikoval (vsechny) pohledy, ze doslo ke zmene - protoze holt MVC ocekava, ze veskere zmeny modelu budou iniciovane z controlleru.

Nebo proste jenom nevim jak na to?

S výhodou lze použít eventbus - model (nebo kdokoliv jiný) vyvolá událost a kdo chce ať si jí naslouchá a podle toho koná, čili jednotlivé komponenty o sobě nemusí vůbec vědět (loose coupling). Tato konkrétní implementace má i speciální podporu pro Swing, která zajišťuje doručování událostí ve správném vlákně.

Otázkou je, zda má zde popisovaná knihovna Nette nebo i Swing ve svých widgetech a view pro zpracování událostí (nebo pattern Observer) podporu.

Osobně si myslím, že v uvedeném příkladu by bylo možné Model a Presenter sloučit. Podle mého chápání MVC oba představují model. Bohužel ale postrádám právě pattern observer, který by zde měl sloužit k notifikacím View, když se změní proměnná $money. Právě proto je potřeba ručně v kodu sáhnout do template a změnit hodnotu (metoda insert).

O tom sloučení by to nebyl zas až tak dobrá nápad, protože to je ta halvní výhoda tohoto návrhu, logika automatu je v Modelu, ale její prezentace v Prezenteru, a když budu chtít změnit například jazyk automatu, vyměním pouze prezenter a nechávám model.

Pořád ten důvod nevidím. V uvedeném případě je chování automatu natolik jednoduché, že by bez problémů šlo do vložit do třídy Prezenter. Pokud by mělo dojít ke změně, patrně bych třídu Prezented upravoval (ve vašem příkladu bych změnil patřičné texty). Pokud by šlo o větší změnu (možnost fungování automatu v různých jazycích), použil bych nějaké sofistikovanější řešení (opět na příkladu jazyka by to bylo nejspíš na bázi překladových katalogů).
Ano, rozumím, že logika fungování automatu může být složitější a bude se muset skládat z vlastních tříd a datových objektů, které mezi sebou budou komunikovat. Tyto objekty pak budou tvořit datový model, což je ale jiný pojem než Model v návrhu MVC.

Klasický problém programátorů. Všechno jde napsat odzhora dolů. Otázka, je, jak je to udržovatelené a znovupoužitelné. Principy dobré objektového návrhu tu nejsou pro nic za nic. ;)

Nejspíš se příliš zaobírám popsaným příkladem. Mým cílem bylo a je říct, že chování automatu, popsané v uvedeném příkladu třídou Model, je datovým modelem, což je něco jiného než "model" v definici MVC. Definici modelu splnuje třída MachinePresenter (představuje model chování automatu pro uživatele).
Problém, který pak v příkladu vidím, je těsná vazba modelu na view (metoda insert), což je přesně to, čemu se MVC model snaží vyhnout.

Model z ukázky rozhodně odpovídá definici modelu v architektuře MVC (a asi by v něm měla být i proměnná $money) a MachinePresenter je zase typickým presenterem v architektuře MVP. Podle mého názoru je ukázka v pořádku.

Nette je psane v PHP pro webove pouziti. Nacteni novych informaci bude iniciovano uzivatelskou akci v prohlizeci, o nejakem sledovani pohledu ze strany modelu nemuze byt asi rec.

Ve vseobecne rovine muze jit o problem implementace MVC, ktera, jak David naznacil, stale neni idealni. Kazdemu vyhovuje jiny styl a take proto vznika spousta MVC frameworku. Ustalena pravidla v ramci architektury mohou byt pro vyvoj aplikace omezujici a tak se casto hledaji klicky a vyjimky pro implementaci specifickych funkci. Robustni MVC systemy se sirokou skalou funkci mohou byt slozite na nauceni, jednoduche MVC systemy zase predpokladaji vetsi zasahy do kodu aplikace ze strany programatora, a tim padem i hlubsi pochopeni kodu a logiky MVC.

Mozna se ptate na metody zacinajici na fire... Napr u AbstractTableModel je napr fireTableDataChanged(), ktera notifikuje vsechny pohledy na tento model, ze se data v tabulce zmenila a maji se prekreslit.
Takze modelu predate nova data a pak zavolate fireNeco podle toho, jaky rozsah chcete obcerstvit (pokud neresite vykon, tak vzdycky vsechno :-) ) a o vic se nemusite starat. V idealnim pripade si aplikace vubec nemusi drzet odkaz na zobrazovaci tridu pote, co ji preda model, vsechno se to obstara vnitrne ve swingu.