Je akorát polovina prázdnin a jsem ve stavu, kdy se snažím načerpat nové síly a inspiraci nejen pro další psaní pro xaml.cz. To mi však nikterak nebrání, abych se věnoval i dalším záležitostem, třeba vývojem aplikací v asp.net MVC.

Jsem technologicky zaměřen a to především na .NET framework, snažím se si stále udržovat přehled, a to i přes to nádherné počasí, které svádí k tomu být co nejvíce venku a užít si nejen dětí a manželky, ale také zrelaxovat u beachvolejbalu.

Nemohl jsem však nepochytit oznámení od Scotta Guthrieho, který právě o těchto prázdninách prezentuje dosažené milníky jednotlivých produktových skupin na cestě k novým releasům. Občas jsem si říkal, škoda nastavených termínů, které jsem si sjednal, protože bych tak o pár dní dříve mohl využít a otestoval Code first development s Entity frameworkem 4 a to na menším projektu pro Pavlík production, který jsem realizoval a který je v současné chvíli v prerelease stádiu.

A právě tento zmíněný projekt využívá asp.net MVC v jeho verzi 2.0 a tak jsem byl velice zvědav na novinky, které přineslo první Preview verze 3.0. Musím se přiznat, že jsem byl celkem zklamán, možná ani ne tak tím, jaké novinky jsem pochytil, ale samotným směrováním. A právě o tom by mělo být toto zamyšlení.

asp.net MVC 3.0 Preview 1

Razor View Engine

Asi první co každého muselo trknout je nový View Engine Razor, který tak doplnil původní engine a jenž by měl mít přehlednější syntaxi. V některých ohledech se tomu tak určitě stalo, na druhou stranu bych si dokázal představit něco jiného, co by bylo stále přehledné, ale zároveň lépe zpracovatelné – tedy založené na xml - alespoň co se týká procesních příkazů. V tomto směru se k tomu velice blíží právě Spark View Engine, ale určitě bych se nebál jít více cestou XAMLu. Ostatně obdobná cesta by se líbila nejen mě, ale třeba i Borkovi.

Globální filtry

Další na řadě jsou globální filtry. Ty určitě budou vítaným příspěvkem pro vývojáře a při snadnosti aplikovatelnosti budou též často využívány. Ono již obdobné globální filtry šli nastavit i nyní a dokonce u nich bylo možné využít Dependency Injection, ale chtělo to napsat si vlastní ControllerFactory a využít taktéž přepsaný ActionInvoker. V této oblasti je to tak jen vyjití vstříc vývojářům, kteří chtějí jít přímo k řešení úkolu a chtějí využít jen dostupné infrasturktury.

dynamic ViewModel

Co však považuji za ne úplně rozumný krok je vlastnost ViewModel a její zdynamičtění. Ano, tato vlastnost plně využívá možností .NET Frameworku 4.0 a je typu dynamic. Což určitě někdo může přivítat, mě to v této chvíli připadá jako velice nerozumné neboť tak vývojář přichází o možnost kontroly šablony ještě před samotným během aplikace a vede to zbytečně k zavlečení chyb v podobě překlepů. To bude vést k ještě většímu důrazu na možnost a nutnost testovatelnosti šablon.

Podpora Dependency Injection

Tady jsem hodně očekával spíše bližší provázanost na MEF (Managed Extensibility Framework) než na implementaci pomocí Common Service Locatoru. V tomto ohledu jsem hodně zvědav na reálné použití, neboť část vývojářů se kloní ke zvolenému použití DI, a ta druhá společný jmenovatel v použití IoC/DI kontejneru zavrhuje. Už asi z pohledu na to, že jsem se u tohoto "vylepšení" zastavil je jasné, že mi to není úplně po srsti a z tohoto pohledu by mi bylo více sympatické, kdyby tato implementace byla založena jen na definici jednotlivých interface pro jednotlivé objekty, které by byly tvořeny pomocí konkrétního DI. To by pak znamenalo mít možnost se vhodně napojit na místo tvorby těchto objektů a připravit je na využití některého ze způsobů DI (pomocí konstruktoru nebo setter vlastnosti), ale z mého pohledu by to bylo dostačující, zbytek by již zajistil daný DI kontejner.

Co mi schází

Dostávám se tak k poslednímu bodu a to k implementaci, která mi schází a kterou bych si dokázal nějakým způsobem představit zahrnutou do asp.net MVC. Touto implementací myslím něco na způsob Screen manageru – zkusím nastínit v dalších řádcích, co si pod tímto pojmem představuji. Je to možná jen tím, že se mi ne úplně líbí způsob, kdy v současné chvíli samotné View má možnost a v některých případech musí volat metody jiných Controllerů, aby byla zajištěna nějaká kompozičnost renderované stránky. A právě to, že až v okamžiku kdy se renderuje View se znovu vytváří kontext a dochází k vyvolání metod a musí dojít k aplikaci filtrů atd. je z mého pohledu velice neefektivní a neúčelné. Navíc si myslím, že kompozici aplikace by nemělo řídit View, ale měl by za tuto činnost být zodpovědný Controller nebo spíše právě zmíněný Screen manager ve spolupráci s Controllerem.

A právě Controller by měl být v kontaktu se Screen managerem a předat mu data Modelu. Manager by pak měl data napojit na dílčí šablony a zajistit rozvržení jednotlivých částí na renderovanou stránku.

Nejspíše by takováto implementace znamenala jiný přístup využití šablon a jejich zpracování, ale samozřejmě by to záviselo na konkrétní implementaci.

Co by však taková implementace měla zaručit je snadnější rozšiřitelnost a modulárnost výsledné aplikace. Plnou kontrolu nad zpracováním jen v Controlleru a tím pádem pasivní View. A umím si představit i další možnosti využití Screen manageru.

Závěrem

Vše zmíněné je jen můj pohled na uveřejněnou první Preview verzi z nového asp.net MVC. V případě posledního bodu pak jen moje přání, které bych rád viděl implementované a podporované. Ono by samozřejmě šlo něco takového implementovat i v dosavadním frameworku, ale přeci jen mít podporu přímo by bylo lepší a zároveň připomínkované větší komunitou vývojářů. Třeba se této myšlenky někdo chytne, rozvine a nakonec ji navrhne, alespoň k zamyšlení ;-)

Comments

Comment 1

Anonymous - on Aug 1 2010 at 1:43 PM

To s tím XAMLem to byl jen vtip, viď? :) Dobrej.

Osobně se mi další směřování ASP.NET MVC taky moc nelíbí a začínám víc zkoumat FubuMVC. To co předvedli v MS s DI je výsměch. Člověk stejně musí přepsat ControllerFactory, takže je tam, kde byl, tedy krom možnosti injektovat services do View a to je opravdu hnus. :) Razor, raději už komentovat nebudu. Sice má chytřejší parser, ale ta syntaxe, jak už jsi psal, je taková, no...

Díky za pěkné shrnutí, koukám, že to vidíme dost podobně :)

Comment 2

Anonymous - on Aug 2 2010 at 11:47 AM

V ASP.NET MVC se moc neorientuje, ale na kompozici ve view nestačí view helpery? V PHP a Zend Frameworku existovalo něco jako controllerAction View helper, který dělal to, co popisuješ Ty, ale nakonec se od toho právě kvůli performace upouští, když nemícháš kód controlleru a modelu, tak view helpery zajistí dostatečný view reuse a kompozici.

A co nějaká kooperace web form komponent a MVC? Už to MS nějak vymyslel? Docela pěkně to má s komponentami vymyšlené Grudl v tom jeho nette.

Comment 3

Anonymous - on Aug 1 2010 at 4:31 AM

Víceméně souhlasím (hlavně příklon k více deklarativním šablonám ala Spark).

Jak to přesně myslíš s tím ScreenManagerem?

Ten by měl stát mezi Controllerem a View? Pak by mohl být implementován jako ActionResult, do kterého by se předalo ScreenName a Model. Ze ScreenName by se "nějak" získalo IScreenManager, které by se pak postaralo o vyrenderování správných Views.

Právě ten posledních krok by chtěl ale hodně promyslet. Jak píšeš - je to jiný přístup ke Views (teď je kompozice řešena pomocí MasterPages (nebo obdobného principu) nebo imperativního kódu).

Druhým problémem posledního kroku by mohlo být to, že až ScreenManager rozhoduje o tom, které Views se budou renderovat a jaká data tedy budou potřeba. To mě přivádí na myšlenku zařazení ScreenManageru spíš ještě před Controllerem, tzn. ScreenManager by určil, jaké Actions volat. Ale celé to mám nedomyšlené :)

Jak bys to chtěl mít Ty?

A mít šablony v XAML, to by byl opravdu zlatý grál :) Z jistého hlediska posun k WebForms, ale na druhou stranu nijak nenarušující princip MVC.

Comment 4

Anonymous - on Aug 1 2010 at 3:03 PM

Ahoj, díky za vaše komentáře, pokusím se nějak reagovat. Snad to nebude příliš dlouhé a bude to aspoň trošku srozumitelné. Začnu hnedka od XAMLu, částečně to byl vtip, protože si nedovedu představit proč by měla být tvorba HTML tak složitá, na druhou stranu, některé prvky bych uvítal. Co se mi příliš nelíbí je nutnost použití příkazů IF a FOR (FOREACH). Určitě by se mi tedy líbilo mít implementovány alespoň DataTemplates. Dále bych se klonil k tomu, aby byla šablona v nějakém snadněji zpracovatelném (automatizovaném) tvaru. Tady mi přijde MS docela nekonzistentní, protože vyvíji nezávislý XAML parser, který by se mohl využít i jinde než ve WPF, Silverlightu a Workflow. A co se týká ScreenManageru, tam je to nakonec na detailnější zamyšlení, ale pokusím se to dát rozumně dohromady, protože jsem o tom přemýšlel již dříve a vypadá to, že by to stálo za rozvinutí.

Comment 5

Anonymous - on Aug 1 2010 at 3:57 PM

V Microsoftu udělali se XAMLem velkou chybu právě v tom, že ho implementovali přimo jako součást WPF a zároveň ho prezentovali jako jazyk pro tvorbu UI, a ne jako deklarativní jazyk pro cokoliv.

XAML určitě jde použít jako ViewEngine, akorát si člověk všechno kolem musí napsat sám a některé věci nejsou tak přímočaré jako v klasickém ViewEngine, ale jde to.

Comment 6

Anonymous - on Aug 2 2010 at 4:05 AM

Ahoj, co se týká XAMLu jako takového, tak v poslední verzi je to již samostatná knihovna, kterou můžeš použít samostatně bez té návaznosti na WPF. A už jsem viděl pár prvních pokusů práce a využití této knihovny, tak snad to bude pokračovat a brzy se třeba dočkáme nějakého XamlViewEngine i pro asp.net :) Jinak se s první částí tvého komentáře shoduji, být to prezentováno maličko jinak a třeba více v souvislosti s WF (kde to už není o té prezentaci), tak by se již vyrojila spousta dalších způsobů využití. Díky

Články z červenec 2010

Malé zamyšlení nad asp.net MVC