Diskusia, posledné príspevky

MVC sa stalo zo dňa na deň asi najfrekventovanejšou skratkou webu a .NETu blízkych blogov. Na druhej strane tu možno nielen ja vnímam paradox, že o to ťažšie je nájsť o problematike MVC kvalitný článok.
Koho problematika naozaj zaujíma a nechce sa boriť s rôznymi derivátmi - derivátov, často plných rôznych mystifikácií, človiečik menom Aviad Ezra(nie, dnes to Martin Fowler nebude) má pre neho peknú sériu článkov.

Klasické MVC, Application model MVC
Od MVC ku MVP
Web MVC (model2)
MVP Winforms vs. WebForms

a ďalšie články s tematikou v autorovom blogu

Aviad nedáva odpoveď len na to, čím MVC bol/je, ale venuje pozornosť tomu, čím by mal/mohol byť vo vzťahu ku rôznym technológiám dnes.
Pochopiť celú historickú púť, jeho rôzne prerody a aplikácie a hlavne motivácie za nimi správane je s jeho článkami pomerne jednoduché. Za všetko len jeden citát:

Smalltalk, ktorý dve desaťročia predtým inšpiroval mnohé frameworky a knižnice s MVC modelom hľadal novú architektúru pre svoj framework novej generácie nazvaný "Dolphin Smalltalk". Preskúmali[Tvorcovia] "Application model" ako poslednú variáciu MVC a vyhodnotili ju ako nevyhovujúcu voči svojim potrebám.[Výrazne sa zmenila filozofia a technológia GUI] Pokračovali v hľadaní až kým neobjavili whitepaper od IBM popisujúci MVP, ktorý bol podobný "Aplication model MVC" ale bol správne pootočený, čo ho robilo oveľa viac vyhovujúcim ich potrebám. Trochu ho oklieštili a prišli so svojou, oveľa jednoduchšou verziou MVP.

Poučenie z toho može byť napríklad takéto. Dnes veľmi (nadplatformovo) roširený Model2 MVC(ktorého derivátom je aj ASP.NET MVC) tu je už nejakých tých desať rokov. Robí to z neho tento fakt automaticky lepší framework? "Klasický MVC" tu bol 20 rokov, tiež bol veľmi široko aplikovaným, ale samotný jeho tvorcovia si uvedomili v istom momente potrebu niečoho, čo by viac zodpovedalo technologickému posunu a ich súčasným požiadavkám. Opodstatnenie frameworku/patternu treba hľadať rozhodne v niečom inom, ako nostalgii a síce v odpovedi na to, ako nám pomáha riešiť naše súčasné problémy a vo vzťahu k súčasným technologickým východiskám. Hľadanie a skúmanie nových prístupov nie je zbytočné, je to to, čo posúva tvorbu software dopredu.

^{P.S. Nie som si istý, či som niektorý z Aviadových článkov už nelinkoval niekedy v minulosti}.

Reakcie

# poznamka 24. 3. 2010 9:38:03 vlko

dolezita je poznamka "[Výrazne sa zmenila filozofia a technológia GUI]" a na prekvapenie vo web technologiach sa filozofia ani technologia GUI nezmenila. Aj ked MS pokus s MVP nebol/nie je zly, proste sa prislo na to, ze navrat ku korenom je tak nejak lepsi.

A MVP veru nezavrhujem akurat by sa podla mna mala preniest zo serveru na clienta, ved pri Silverlight/WPF aplikaciach nad MVC nikto nepremysla, lebo sa tam nehodi.

A este poznamka ku "MVC sa stalo zo dňa na deň asi najfrekventovanejšou skratkou webu a .NETu blízkych blogov.". Osobne si to nemyslim, stale vychadza dostatok clankov a blogov na temu asp.net, len mna (ako jedneho z prispievatelov do spraviciek) to uz tak nezaujima, pretoze je to len variacia na nieco co tu uz bolo. Asp.mvc je momentalne hype tema a ako vzdy takyto hype casom vyprsi, ale posnazim sa ho udrzovat co najdlhsie:)

# .. 24. 3. 2010 10:14:12 T

@vlko: Naozaj nezmenila? Ajax a v pripadne webForms ... (aj pri winformach si mozes handlovat win messages v controlleri a robit view/widgety, ale robis to? Jasne, ze nie.)

plus zmena v poziadavkach ... komplexnejsie GUI controly, komplexnejsia logika, intranetove aplikacie. (samozrejme, toto sa snazi reflektovat aj ASP.NET MVC)

"proste sa prislo na to"
Sa neprislo :-) Niekto si to mysli a dovody preco si to mysli mozu byt rozne, ale uz sa mi nad tym nechce metidovat zase.

Model2 je mozno navratom ku "korenom", otazka akym(ku model2 nie povodnemu MVC, to sa ani neda), cize ASP.NET MVC je tiez len nejaka aplikacia MVC...
View -> je skor screen a nie control/widget
View -> je pasivny
(Domain) Model -> nie je observovatelny, navyse je tu este nieco co sa vola VM.
"Controller" -> pracuje s akciami, eventami, ktore su "emulovane" cez view link helpre s vyuzitim urlka (tu je podobnost s povodnym C v tom, ze user input nespracovava priamo view). Pri WebForms capturuje eventy control / view za cenu zapajania javascriptu client side ale daju sa tak lahsie riesit komplexnejsie situacie. Oba aplikacie patternu celia rovnakemu problemu, bezstavovosti HTTP a cim su Screeny komplexnejsie, tym je to naliehavejsia vec.
Reinkarnovaniu model2 pomaha paradoxne prave ajax a client side(co je samozrejme zneuzivane skor ako vycitka voci ASP.NET), pretoze do riesenie urcitych taskov, ktore su s cistym model2 neriesitelne/tazko riesitelne sa silno zapaja js.

V konecnom dosledku Passive View s WebForms a model2 MVC s ASP.NET MVC maju ku sebe daleko blizsie, ako by malo zmysel hladat paralely s povodnym MVC.

# winforms mvp 24. 3. 2010 10:31:27 Looser

dik za pekny link na tie formy, dlho som nevedel najst nejaky rozumny priklad, chcel som si porovnat so svojim riesenim, toto miz as rozsirilo obzory.
akurat este rozmyslam ako skompinovat MVP a v rozumnej moznej miere vyuzivat moznosti winforms bindingu (Observer pattern)

# tak inak 24. 3. 2010 11:00:26 vlko

ok, mozno sa na celu temu pozerame obaja zle. Co ked je pravda ta, ze sa pomocou asp.net snazime web ohnut tam, kam su urcene ine architektury, teda do RIA (teraz hovorim o webe bez ajaxu). Nehodi sa na to viac Flex/Silverlight.
No ak zoberieme do uvahy web s ajaxom, tak sa vynara otazka, ci ma zmysel managovat state na serveri a preco pridavat serveru zbytocny load spojeny s rekonstrukciou stavu, alebo ci to nebude lepsie presunut na server.

Neobstoji ani argument, ze asp.net aplikacia je spustitelna vsade, kde je web, pretoze postbacky si bez javascriptu ani neskrtnu, takze preco potom celu state logiku nepresunut na clienta?

No a pri ajax aplikaciach mame dva sposoby full client rendering a tu uz potom aj asp.mvc straca zmysel a treba sa obratit na wcf, alebo server rendering, v ktorom je asp.mvc ovela praktickejsi ako asp.net.

Do tohto kontextu mi asp.net proste nezapada, ale to neznamena, ze sa v tomto kontexte pouzit neda, ano vacsina asp.net intranet aplikacii takto bezi a nikomu to nevadi, z jednoducheho dovodu, vsetko je pokryte komponentami a takyto vyvoj je velmi rychly. Otazne je, ci sa v nejakej blizkej/vzdialenej dobe az budu RAD nastroje s frameworkom na vyvoj niecoho ako asp.net na strane klienta sa nestane z asp.net obsolete technologia.

# ... 24. 3. 2010 14:55:07 T

@Looser: skor by som isiel cestou passive view s viewmodelom a pouzil ten isty pristup ako pouzivam pri web formach...mat controly, ktore maju .Value ktora je uz typova, nie string. Nepouzivat systemovy binding, ale svoj vlastny cez tuto hodnotu. Ostatne properties mozes bindovat cez ten.
Neviem, ci to takto bez kodu pomoze a dava zmysel

@vlko:
Ja neviem, zase take nejake divne argumenty(nemyslim to v zlom, ale pride mi to len ako hranie sa so slovickami)

"Ohybanie do RIA...Nehodi sa na to viac Flex/Silverlight?..."

Hodi sa na to to, co je u zakaznika akceptovatelne. A v podstate RIA je len taka marketingova nalepka pre tucniaka.

"Neobstoji ani argument, ze asp.net aplikacia je spustitelna vsade, kde je web, pretoze postbacky si bez javascriptu ani neskrtnu, takze preco potom celu state logiku nepresunut na clienta?"

Kto tym argumentuje, ale urcite je dostupnejsia a lhasie dostupnejsia a Silverlight aj z hladiska nejaky novych moznych deviceov.
A ako si poradis pri komplexnejsich scenaroch s ASP.NET MVC bez javascriptu? Nijako. Su situacie, kedy je JS prijatelnym predpokladom.(a v pripade intranetu na 100%). Ano asp.net infra sa mohla vysporiadat aj s tym, ze urobis submit bez javascriptu(vies zistit, ze bol stlaceny konkretny buttton), ja to mam napr. v PHP WebForms :-) ci ako to nazvat frameworku vyriesene.

"No ak zoberieme do uvahy web s ajaxom, tak sa vynara otazka, ci ma zmysel managovat state na serveri a preco pridavat serveru zbytocny load spojeny s rekonstrukciou stavu, alebo ci to nebude lepsie presunut na server."

Potom ideme ale tymto smerom v uvahe, teda ci ma vobec zmysel riesit nejaku prezentacnu logiku server side a ci potrebujeme server side framework. Nepotrebujeme a to tu uz prezentujem davno :-)
Btw. rekonstrukcia stavu a co myslis ze je to id v urlku, alebo zbieranie dat z postu za ucelom znova ich vyrenderovat klientovi pri ASP.NET MVC?
(nehovoriac a tempData,ViewState,ControlState)

"No a pri ajax aplikaciach mame dva sposoby full client rendering a tu uz potom aj asp.mvc straca zmysel a treba sa obratit na wcf, alebo server rendering, v ktorom je asp.mvc ovela praktickejsi ako asp.net."
V com vidis tu vacsiu praktickost pri server side render? Ze sa musis zaoberat nejakym kodom client side aby si si zabezpecil server side obnovenie stavu?(pchal vsetok stav napr. do linky) Super. Nam staci napr. update panel.

# forms binding 24. 3. 2010 15:38:54 Looser

zmysel to dava
ale zober si scenar
na lavo grid
na pravo detail ktory zobrazuje entitu podla toho na ktorom riadku stojis v gride, ked sa pohnes, detail sa zmeni

toto uz forms binding riesi, a kym to nakodis s passive view, tak to niekto iny stihneaj vyfakturovat

# re:.. 24. 3. 2010 16:02:13 vlko

to T: nechcem ta nejak vyrusovat v toku myslienok, ale asp.mvc podobne ako asp.net pozna POST request, dokonca ma na post request automaticky binder

# ... 24. 3. 2010 19:03:37 T

@looser:
MVX prinasa komplexitu navyse, to je dan, tiez nezastavam nazor, ze sa do toho oplati ist vzdy.
Neviem sa prepnut na win formy momentalne, aby som posudil narocnost, tak nechcem improvizovat.

ale ten sampel mi pripomenul este toto - presentation model?
http://martinfowler.com/eaaDev/PresentationModel.html

@vlko: ano, toho som si vedomy, vid vyssie, len mi unika pointa ku comu to bolo :-(

# re:... 24. 3. 2010 20:38:54 vlko

to T: k poslednemu odstavcu, ale neva:)

# ... 24. 3. 2010 22:58:53 T

@vlko: chapem...a ako to vyuzijes priamo pri ajaxe a server side renderingu?(posledny odstavec) Budes robit POST Ajax request a zberkat manualne data z formu do request headru?

# RE:.. 24. 3. 2010 23:11:40 vlko

to T: je na to helper Ajax.BeginForm

# ... 25. 3. 2010 12:04:24 T

@vlko: ten neriesi "okolie" daneho formu, co nie je tak ani technicky problem(ze by sa to nedalo poriesit) ale principialny... v momente ak by si s "okolym" pocital kazdej moznej action metode controlleru tak vznika neskutocna uzka previazanost ... straca sa zmysel partial view(alias niecoho ako controlu?) zmena v okoli daneho partial view, by znamenala touchnutie vsetkych relevatnych controller metod.

# re:... 25. 3. 2010 12:18:59 vlko

to T: bez scenara si myslim je tazko sa bavit o taketo teme, vseobecne riesenie neexistuje, teda mozno pri asp.net ma take nieco zmysel v spojeni s viewstate.
Inac ked sme pri tom viewstate, tak napr ten dokaze dost ovplyvnit tvoje myslenie pri web aplikaciach a nakoniec mozes skoncit tak ako ja alebo ty, ze ho nasimulujes aj v php:)

# ... 25. 3. 2010 16:27:46 T

@vlko: scenar som uz kedysi myslim daval, kedze sme to uz riesili.

tou druhou vetou neviem presne, co si chcel povedat. Ja rozlisujem medzi controlState(Esential) a viewState(Skor Caching). ControlState sme vsetci pouzivali uz davno predtym, len sme si to riesili rucne cez hidden fields. Co sa tyka mna a PHP tak supportujem len controlState (zatial len serialize , co nie je nastastnejsie a najoptimalnejsie, ale lepsie ako hidden field per potreba)