asp.net MVC Best practices – shrnutí
Ve středu večer proběhla diskuze v půlkulatém kruhu na téma asp.net MVC Best practices, kterou se mi povedlo uspořádat v prostorách Microsoftu a pozvat na ni zástupce různých technologií.
Něco málo k organizaci
Dřív než se dostanu k samotnému shrnutí získaných informací, dovolím si uvést několik málo informací k organizaci a průběhu samotné diskuze. Tato totiž dopadla nad očekávání dobře a dle reakcí účastníků to není jen můj osobní pocit, za což jsem velice rád a musím především zúčastněným poděkovat. Maličko jsem se totiž obával, když jsem sezval zástupce různých technologií, aby diskuze nesklouzla k flame-ování, ve výsledku z toho byla však konstruktivní debata trvající téměř 3 hodiny, a po ní ještě flám-ování. Je vidět, že pokud se sejdou lidé, kteří mají spoustu znalostí a zkušeností, dokáží být nad věcí a přistoupit k diskuzi konstutivně. Zároveň se pak velice snadno dokáží přizpůsobit a orientovat se i v jiné technologii, jelikož se zde řeší stejné úlohy, pomocí stejných vzorů, jen s odlišnou implementací.
Pro příště mám však jedno ponaučení, zúčastnění by se měli na takovéto diskuzi osobně představit. Přestože jsem připravil vizitky velikosti A4 se jménem a zastoupenou technologií, nebylo to dostačující. A tak David Grudl (Nette PHP) zjistil až někdy kolem půlnoci, že se zúčastnil také Michal Bláha (.NET WebForms). Zajímavá chvilka taktéž nastala při diskuzi, kdy Vlasta Vávrů (Java, PHP) se podivil nad komplexností deploymentu popisovaného Honzou Králem (Django). Zajímavé postřehy pak měli také Karel Minařík (Rails), Borek Bernard (Flex) a Daniel Kolman (.NET MVC). Musím též poděkovat Aleši Roubíčkovi a Michalu Augustýnovi za pomoc a podporu při organizaci. Samozřejmě patří dík i ostatním, kteří se zúčastnili a zapojili se do diskuze.
Ostatním, kteří měli zájem se diskuze zúčastnit, nebo mají zájem dozvědět se závěry z diskuze mám potěšující zprávu, v dohledné době proběhne přednáška na téma asp.net MVC, kde budou prezentovány závěry z uskutečněné diskuze vzešlé.
Pro nedočkavce – shrnutí MVC Best practices
Myslím, že velice detailní shrnutí již sepsal Borek Bernard v ohlédnutí z diskuze o MVC a svůj pohled na, asi jedinou flame diskuze, pak Tomáš Herzeg o rozdílech mezi WebForms a asp.net MVC.
Přidám tedy jen svůj pohled, který doufejme doplní výše uvedené články. Co jsem si odnesl z diskuze já a co mě velice potěšilo, že jsem se vesměs se svými předchozími články popisujícími použití MVVM v asp.net MVC celkem trefil do toho, jak uvažují i ostatní o přístupu k implementaci MVC principu pro webové aplikace. Právě David Grudl popisoval velice podobný scénář, který použil v Nette pomocí “plniče” Presenteru, jako jsem uvedl v článku jak vypadá ViewModel v asp.net MVC.
V hlavní roli Model
Co je třeba si uvědomit při využití jakékoliv implementace MVC je role Modelu. Jak zmínili téměř všichni přítomní, především u začínajících vývojářů je Model považován za databázi, což určitě není. Model představuje data, která jsou připravena k zobrazení. Na co určitě zapomeňte je předávání DataContextu do View, pokud chcete využít třeba LINQ2SQL nebo Entity Framework. Maličko lepší službu už uděláte v případě, že předáte jen vygenerované datové objekty, na mnoha malých webech to bude dostačující. Jestliže však uvažujete o něčem větším, vytvořte si vhodný view model, který bude respektovat potřeby pro zobrazování v aplikaci, nikoliv potřeby relační databáze. Do modelu se pak nebojte zahrnout i podpůrné vlastnoti vhodné při zobrazování dat.
Jednoduchý Controller
Citovat Davida si dovolil již Borek, já mohu jen souhlasit. Controller by měl být co nejjednodušší. Měl by se postarat jen o výběr vhodného ViewModelu (Presenteru), zvalidovat vstupní data a vybrat šablonu (View), která provede zobrazení dat. Případně se samozřejmě postará o přesměrování na jinou akci, což je jen o tom, že vybere jiný ViewModel a jinou šablonu, která se zobrazí.
Pasivní View
Přesně tak, nesnažte se do View vkládat složitější logiku než je jen vypsání dat na potřebná místa. Šablony v asp.net MVC mohou svádět k tomu je vytvořit aktivní a manipulovat zde s Modelem, obzvláště pak v případě, že si do View předáme potřebné objekty typu DataContext. Dobrým řešením by mohlo být použití takového ViewEngine, který dovoluje pouze deklarativní zápis, případně komponentové poskládání stránky – obdobně jako bylo představováno frameworkem Django.
Nenecháme si to pro sebe?!
Samozřejmě je toho víc a výše zmíněné je jen to hlavní co mi utkvělo v paměti. O další informace se budu chtít s vámi podělit. Kdy to konkrétně bude ještě nevím, ale určitě sledujte vypisované akce. A není to vše, jak jsem se již zmiňoval v úvodu, snad všichni pozvaní vývojáři byli uspořádáním takovéto akce nadšeni a rádi se zúčastní obdobných diskuzí. A jelikož se více jak půl hodinu taktéž diskutovalo o testování aplikací, předběžně jsme se domluvili na tomto tématu. Představa je formou panelové diskuze, tudíž pokud bude mít někdo zájem, určitě se bude moci zúčastnit.
Budu se tedy těšit na brzkou viděnou se všemi zájemci o vývoj pomocí asp.net MVC.
Comments
Aleš Roubícek
Ješte jednou díky za organizaci a za shrnutí. Jen si dovolím nesouhlasit s tvrzením že: "Model predstavuje data." To je stejná chyba, že predstavuje databázi. Model je defacto aplikace. Mužou to být služby, které poskytují data, nebo posílají SMSky, to je fuk. :) Doufám, že je zrejmé, co chci ríct. Model je mnohem bohatší než databáze, nebo data, která se mají vypsat.
Jarda Jirava
2Tomas: Ano máš pravdu, vzal jsem to jen z jednoho pohledu, pro zobrazování dat. Pokud je potreba data uložit, má se o toto postarat práve Model, resp. v modelu zahrnuté servisní vrstvy, které data uloží. Ale tuším jsem toto prezentoval v predchozích cláncích na které se odkazuji.
Aleš Roubícek
Pozor na duležitou vec Model != ViewData.Model :)
Jarda Jirava
Ano, správne jsi to pochopil. :-)
Tomas
"Model predstavuje data, která jsou pripravena k zobrazení"
To snad nie. A modifikacie sa nedeju cez model? Hento zodpoveda skor definicii query modelu s DTO(Data Transfer Objekt) pri query/command separacii.
Je dalsi a velky omyl trosku pokrocilejsich programatorov, ze v modely nedokazu vidiet aj behavior.
Predpokladam, ze to vypliva z takejto architektury, ktoru pouziva autor: Service vrstva v ktorej je behavior(=Fowler: Transaction script pattern) + DTO. Model zahrna v tomto pripade samozrejme aj tzv. servisnu vrstvu, v nej je totiz pri takejto architekture behavior a nie je to len facade...nad domain modelom). Pre to, co sa tlaci do views v ASP.NET MVC beriem este oznacenie "ViewModel".
..a ak hovorime o modely a MVC patterne, tak pod M spada aj GUI logika.(hovorime o modely aplikacie, v predpotopnych aplikaciach nemalo zmysel oddelovat domain model a gui logiku) Je to len specialitka modelu 2, ze to, co sa v nom nazyva "controller" riesi GUI logiku.(v horsom pripade ako bolo spomenute v clanku aj business logiku) GUI logika spada pod aplikacnu logiku, ktoru v povodnom MVC zastresovala M vrstva.
A vseobecne, jeden z najvacsich problemov pri dnesnej MVC flame su podla mna pojmy.
Jarda Jirava
Aleši, pokud by Model byly služby jak ríkáš, tak by jsi tyto služby mel možnost volat ve View, což urcite není žádoucí. Tyto služby by meli být soucástí modelu/aplikace, ale mely by být skryty a šablona by již mela dostat jen data pro zobrazení. S poslední vetou pak mohu souhlasit. Je to z duvodu, kdy potrebuji pridat treba zminované komentáre do výstupu a predtím jsem o nich "nevedel". Je však možné, že naše chápáni Modelu je posunuté a osobne mám aplikaci více separovánu.
Tomas
@Jarda: to vysvetlenie by som bral, keby si nepridal aj odpoved pre Alesa.(tu som prehliadol a hovori o tom istom ako ja vyssie, len jednoduchsie)
Model, v najsirsom slova zmysle je aplikacia, je to aplikacny model, aplikacna logika. Tak to bolo chapane pri klasickom MVC.
Model2 ale meni paradigmu, definiciu pojmov, do controlleru pcha tu cast aplikacnej logiky, ktora je zodpovedna za GUI a za pracu s modelom. V konecnom dosledku je model2 viac MVP ako by malo blizko povodnemu MVC. Takze ak model2 dava do C vrstvy cast aplikacnej logiky, co je potom M vrstva? Business logika(alebo priamo data access ak business logika absentuje). Je vela patternov ako organizovat business logiku. U Teba je to anemicky model s tranzaction scriptami a DTO(ktore pouzijes priamo na zobrazenie vo view).Ale M moze byt napr. domain model pri DDD, alebo service facade nad domain modelom atd. tych sposobov organizovania M vrstvy je vela, vid napr. PoEAA
Transaction Script http://martinfowler.com/eaaCatalog/transactionScript.html Domain Model http://martinfowler.com/eaaCatalog/domainModel.html Table Module http://martinfowler.com/eaaCatalog/tableModule.html Service Layer http://martinfowler.com/eaaCatalog/serviceLayer.html ) "osobne mám aplikaci více separovánu." Presne tak. Ide o separaciu.
Pri tom, ako je postavena architektura model2 mozes v C vytvarat projekciu vysledkov z query metod domain modelu - tieto DTO(immutable) urcene na zobrazenie volajme viewModel. Nasledne ich mozete tlacit do view ako si to robil doteraz.
Jarda Jirava
2Tomas: Ale všimni si, že já do C nedávám žádnou cást aplikacní logiky a doufám, že jsem to tak nikde nenapsal. Do C dávám validaci vstupních dat, což ovšem neznamená, že validaci nemám též v modelu (Business vrstve aplikace). Validaci na této úrovni však nepovažuji za aplikacní logiku, resp. je to vložení validace na co nejvyšší úroven k uživateli. Stejne tak v C nevytvárím projekci výsledku z query metod domain modelu o to se již stará ViewModel alias "plnic" jak jej zminoval David - jestli jsem mu tedy porozumel správne. Je však možné, že jsem úplne vedle a pokud nekdo sepíše lepší povídání, tak se nechám poucit, když už me nepoucila diskuze ;-)
Jarda Jirava
Tak cestou volit a zpet jsem prišel na to, proc zde došlo k takovémuto nedorozumení. Jak psal Tomas, je to o názvosloví a tak se pokusím vše dovysvetlit. Chce to však samostatný clánek, do komentáre se mi to urcite nevejde. Díky tedy za upozornení, poznal jsem, že je treba vše více vysvetlit, pokud se pouštím do oblasti, kde muže názvosloví delat problém.
Michal Augustýn (Augi)
S tím Davidovým plnicem jsem to pochopil úplne stejne a presne tak to používám. Ohledne validace - osobne v C (príp. to propaguji do JavaScriptu) delám predevším "input" validaci (uživatel fakt zadal císlo, takže ho mužu priradit do property typu int apod.) - tu zajištuje DefaultModelBinder.