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í ;-)