asp.net MVC Best practices – shrnutí

Jun 4 2009 5:17 PM

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.

10 Comments

  • Aleš Roubíček said

    Ještě jednou díky za organizaci a za shrnutí. Jen si dovolím nesouhlasit s tvrzením že: "Model představuje data." To je stejná chyba, že představuje databázi. Model je defacto aplikace. Můžou to být služby, které poskytují data, nebo posílají SMSky, to je fuk. :) Doufám, že je zřejmé, co chci říct. Model je mnohem bohatší než databáze, nebo data, která se mají vypsat.

  • Jarda Jirava said

    2Tomas: Ano máš pravdu, vzal jsem to jen z jednoho pohledu, pro zobrazování dat. Pokud je potřeba data uložit, má se o toto postarat právě Model, resp. v modelu zahrnuté servisní vrstvy, které data uloží. Ale tuším jsem toto prezentoval v předchozích článcích na které se odkazuji.

  • Tomas said

    "Model představuje data, která jsou připravena 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 said

    Aleši, pokud by Model byly služby jak říkáš, tak by jsi tyto služby měl možnost volat ve View, což určitě není žádoucí. Tyto služby by měli být součástí modelu/aplikace, ale měly by být skryty a šablona by již měla dostat jen data pro zobrazení. S poslední větou pak mohu souhlasit. Je to z důvodu, kdy potřebuji přidat třeba zmiňované komentáře do výstupu a předtím jsem o nich "nevěděl". Je však možné, že naše chápáni Modelu je posunuté a osobně mám aplikaci více separovánu.

  • Tomas said

    @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
    )
    "osobně 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 said

    2Tomas: Ale všimni si, že já do C nedávám žádnou část aplikační 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 vrstvě aplikace). Validaci na této úrovni však nepovažuji za aplikační logiku, resp. je to vložení validace na co nejvyšší úroveň k uživateli. Stejně tak v C nevytvářím projekci výsledků z query metod domain modelu o to se již stará ViewModel alias "plnič" jak jej zmiňoval David - jestli jsem mu tedy porozuměl správně. Je však možné, že jsem úplně vedle a pokud někdo sepíše lepší povídání, tak se nechám poučit, když už mě nepoučila diskuze ;-)

  • Jarda Jirava said

    Tak cestou volit a zpět jsem přišel na to, proč zde došlo k takovémuto nedorozumění. Jak psal Tomas, je to o názvosloví a tak se pokusím vše dovysvětlit. Chce to však samostatný článek, do komentáře se mi to určitě nevejde. Díky tedy za upozornění, poznal jsem, že je třeba vše více vysvětlit, pokud se pouštím do oblasti, kde může názvosloví dělat problém.

  • Michal Augustýn (Augi) said

    S tím Davidovým plničem jsem to pochopil úplně stejně a přesně tak to používám.
    Ohledně validace - osobně v C (příp. to propaguji do JavaScriptu) dělám především "input" validaci (uživatel fakt zadal číslo, takže ho můžu přiřadit do property typu int apod.) - tu zajišťuje DefaultModelBinder.

Add a Comment