Postřehy ohledně architektury JavaScriptu

[gl]

Přece View se na nic neptá, to ten změněný Model spouští řetězec událostí, podle kterých se View aktualizuje, nebo ne?

Bavíte se o webových aplikacích?

O architektonickom vzore MVC.   

A podla mojho nazoru je to zlozitejsie napisane, ze sa view nakoniec spyta, ale ok, uz to necham tak.
Tieto akademicke debaty ma nikdy nebavili, preto som phd nedorobil.

Mimo root jsem nepotkal akademika, který by se zabýval něčím podobným. S vědou to nemá nic společného.

To co píše Honza se mi moc nezdá. Já MVC rozumím tak, že View je funkce requestu a modelu, která vrátí response. Controler je funkce requestu, která vybere View. Modifikace modelu na tom nic nemění. Určitě existuje spousta interpretací. Tohle je jedna z nich, ze které vychází Django.

[Reklama]

[Kit]

Problem je, ze se "pta" na stav. To je uz samotne "asking", co by nemal robit.

Přece View se na nic neptá, to ten změněný Model spouští řetězec událostí, podle kterých se View aktualizuje, nebo ne?

View dostane notifikaci (je vcelku jedno odkud), ale žádná data. Ta data si vyptá z Modelu a podle nich se aktualizuje. Není na tom nic špatného. Pouze to ukazuje, že pravidlo "Tell, don't ask" se nedá používat univerzálně na všechno. V rámci jednoho modulu je však velmi užitečné - v podstatě eliminuje potřebu většiny getterů.

[Kit]

To co píše Honza se mi moc nezdá. Já MVC rozumím tak, že View je funkce requestu a modelu, která vrátí response. Controler je funkce requestu, která vybere View. Modifikace modelu na tom nic nemění. Určitě existuje spousta interpretací. Tohle je jedna z nich, ze které vychází Django.

Interpretací architektury MVC je více a je v tom docela chaos. MVC se vyskytuje na různých úrovních aplikace a dokonce se dá najít i uvnitř každého objektu. Vypadá to, že Django to má vyřešeno docela dobře.

V mém webovém pojetí: Vše, co přijde metodou GET, je nasměrováno do View. Vše, co přijde metodou POST, je nasměrováno do Controlleru. Oba tyto moduly pracují s Modelem. View z něj pouze čte, Controller pouze zapisuje.

[Honza]

To co píše Honza se mi moc nezdá. Já MVC rozumím tak, že View je funkce requestu a modelu, která vrátí response. Controler je funkce requestu, která vybere View. Modifikace modelu na tom nic nemění. Určitě existuje spousta interpretací. Tohle je jedna z nich, ze které vychází Django.

Interpretací architektury MVC je více a je v tom docela chaos. MVC se vyskytuje na různých úrovních aplikace a dokonce se dá najít i uvnitř každého objektu. Vypadá to, že Django to má vyřešeno docela dobře.

V mém webovém pojetí: Vše, co přijde metodou GET, je nasměrováno do View. Vše, co přijde metodou POST, je nasměrováno do Controlleru. Oba tyto moduly pracují s Modelem. View z něj pouze čte, Controller pouze zapisuje.

Doufám, že je to zmatení pouze v pojmech, podle mě, pokud ten View Model pouze čte, tak to není porušení toho principu "Tell, Don't Ask", o kterém je řeč.
O interpretaci MVC vůbec nejde, ani o implementaci na serveru.

[balki]

Přece View se na nic neptá, to ten změněný Model spouští řetězec událostí, podle kterých se View aktualizuje, nebo ne?

Bavíte se o webových aplikacích?

O architektonickom vzore MVC.   

A podla mojho nazoru je to zlozitejsie napisane, ze sa view nakoniec spyta, ale ok, uz to necham tak.
Tieto akademicke debaty ma nikdy nebavili, preto som phd nedorobil.

Mimo root jsem nepotkal akademika, který by se zabýval něčím podobným. S vědou to nemá nic společného.

To co píše Honza se mi moc nezdá. Já MVC rozumím tak, že View je funkce requestu a modelu, která vrátí response. Controler je funkce requestu, která vybere View. Modifikace modelu na tom nic nemění. Určitě existuje spousta interpretací. Tohle je jedna z nich, ze které vychází Django.

Mno, to je computer science, a ja som tych akademikov stretol dost. Aplikacie sa rozrastaju a modularita, a potencialne rozsirenia oop su dost horuca tema. Bol som na aosd 2012 a na  ecoop  2011. Tam sa mi nezdalo, ze by sa nikto tym nezaoberal.

[Reklama]

[javaman ))]

To jsou nějaký lopaty, to nesmíš řešit. Taky by ses mohl týdny bavit o blbostech s kitem a nikam by to nevedlo.

[balki]

Doufám, že je to zmatení pouze v pojmech, podle mě, pokud ten View Model pouze čte, tak to není porušení toho principu "Tell, Don't Ask", o kterém je řeč.
O interpretaci MVC vůbec nejde, ani o implementaci na serveru.

Ok, v akej literature je to vysvetlene? Pocujem to prvy krat, rad sa nieco nove dozviem.

[Kit]

Doufám, že je to zmatení pouze v pojmech, podle mě, pokud ten View Model pouze čte, tak to není porušení toho principu "Tell, Don't Ask", o kterém je řeč.
O interpretaci MVC vůbec nejde, ani o implementaci na serveru.

Ok, v akej literature je to vysvetlene? Pocujem to prvy krat, rad sa nieco nove dozviem.

Zkus začít třeba tady: https://www.zdrojak.cz/clanky/uvod-do-architektury-mvc/

[balki]

Doufám, že je to zmatení pouze v pojmech, podle mě, pokud ten View Model pouze čte, tak to není porušení toho principu "Tell, Don't Ask", o kterém je řeč.
O interpretaci MVC vůbec nejde, ani o implementaci na serveru.

Ok, v akej literature je to vysvetlene? Pocujem to prvy krat, rad sa nieco nove dozviem.

Zkus začít třeba tady: https://www.zdrojak.cz/clanky/uvod-do-architektury-mvc/

Na tell don't ask som sa pytal. MVC, je pecene varene, najlepsi vyklad vzoru je v knizke od Gang of four.

Co je to ten zahadny "tell don't ask"?

[Kit]

Co je to ten zahadny "tell don't ask"?

Poměrně dobře vysvětleno a je tam i pár pravidel navíc:
https://pragprog.com/articles/tell-dont-ask

Motto: Procedural code gets information then makes decisions. Object-oriented code tells objects to do things.

[balki]

Pravidlo Tell, don't ask má také své omezení. Například View v architektuře MVC ho porušuje a nikoho to netrápí.

Jak ho porušuje??

Ked model zmeni svoj stav, tak view je notifikovany modelom, aby si stiahol nove data z modelu. Model si nasledne tieto data stiahne.  Cize view si pyta vnutorny stav modelu, ktory by podla tejto zasady, ktoru nepoznam, nemal vediet.

Tak mne napadá, co kdyby model místo notifikace rovnou poslal diff mezi old a new state ? View by si to pak přebralo.

To je vzor mediator, uz by to nebolo "celkom tak MVC"

Ako pozeram, aj mate pravdu, existuju 2 pristupy k updatovaniu protokolu

K vzoru observer (vztah Model - View):

Avoiding observer-specific update protocols: the push and pull models. Implementations of the Observer pattern often have the subject broadcast additional information about the change. The subject passes this information as an argument to Update. The amount of information may vary widely.
At one extreme, which we call the push model, the subject sends observers detailed information about the change, whether they want it or not. At the other extreme is the pull model; the subject sends nothing but the most minimal notification, and observers ask for details explicitly thereafter.
The pull model emphasizes the subject’s ignorance of its observers, whereas the push model assumes subjects know something about their observers’ needs. The push model might make observers less reusable, because Subject classes make assumptions about Observer classes that might not always be true. On the other hand, the pull model may be inefficient, because Observer classes must ascertain what changed without help from the Subject.

[Kit]

Co je to ten zahadny "tell don't ask"?

Tady je to i s ilustračním obrázkem:
http://martinfowler.com/bliki/TellDontAsk.html

[balki]

Co je to ten zahadny "tell don't ask"?

Tady je to i s ilustračním obrázkem:
http://martinfowler.com/bliki/TellDontAsk.html

Dakujem, toto je dokonca od jedneho z najvyssich iluminatov, bude to serious business.
Aspon nieco uzitocne z tejto diskusie ziskam.

[balki]

Pravidlo Tell, don't ask má také své omezení. Například View v architektuře MVC ho porušuje a nikoho to netrápí.

Jak ho porušuje??

Ked model zmeni svoj stav, tak view je notifikovany modelom, aby si stiahol nove data z modelu. Model si nasledne tieto data stiahne.  Cize view si pyta vnutorny stav modelu, ktory by podla tejto zasady, ktoru nepoznam, nemal vediet.

Tak mne napadá, co kdyby model místo notifikace rovnou poslal diff mezi old a new state ? View by si to pak přebralo.

To je vzor mediator, uz by to nebolo "celkom tak MVC"

Ako pozeram, aj mate pravdu, existuju 2 pristupy k updatovaniu protokolu

K vzoru observer (vztah Model - View):

Avoiding observer-specific update protocols: the push and pull models. Implementations of the Observer pattern often have the subject broadcast additional information about the change. The subject passes this information as an argument to Update. The amount of information may vary widely.
At one extreme, which we call the push model, the subject sends observers detailed information about the change, whether they want it or not. At the other extreme is the pull model; the subject sends nothing but the most minimal notification, and observers ask for details explicitly thereafter.
The pull model emphasizes the subject’s ignorance of its observers, whereas the push model assumes subjects know something about their observers’ needs. The push model might make observers less reusable, because Subject classes make assumptions about Observer classes that might not always be true. On the other hand, the pull model may be inefficient, because Observer classes must ascertain what changed without help from the Subject.

Je to v sekcii problemov, ktorym sa treba vyhnut. Zle citam.

Pull, je tahanie bez notifikacie.

Push je prave posielanie stavu subjektom (modelom).

Sorry, vraj sa to nema tak tobit.

[SB]

Gettery a settery su hlavne na to, aby konstruktor objektu nemusel mat kilometer. Vhodne pouzitie je konfiguracia objektu a zistovanie jeho stavu.

Pouzivanie v objektoch, ktore su vlastne mudrejsie "structy" sa mi sice nepaci, ale niekedy je ozaj potrebne zmenit spravanie pri nastaveni fieldu (atributu). Vtedy sa to hodi.

Gettery a settery jsou především vznosným názvem pro jedny z mnoha metod, které zprostředkovávají komunikaci mezi vnějškem a vnitřkem objektu. Problémem je, že v mnoha začátečnících vyvolávají dojem, že každá vlastnost objektu má mít svůj getter a setter, což by skutečně vedlo na porušení zapouzdření u některých vlastností. Další chybou je, že u některých jazyků mají extra syntaktické řešení - zbytečnou komplikaci a jisté důsledky. Smalltalk se obešel bez nich, aniž by to čemukoliv vadilo.