Vzhledem k tomu, že posledních pár týdnů používám v jednom větším projektu technologii ASP.NET Dynamic Data, rozhodl jsem se sepsat zkušenosti, které jsem při práci s tímto “frameworkem” získal. Nehodlám zde rozepisovat návod, jak technologii použít, na to se specializují jiné články, například článek Představení ASP.NET Dynamic Data Štěpána Bechynského. Jde spíš o praktické postřehy, na něž při práci s DD narazíte.
Co je ASP.NET Dynamic Data?
Stručně řečeno jde o technologii, která umožňuje generování uživatelského rozhraní ze schématu databáze. Vychází se z toho, že většina požadavků na dnešní webové aplikace je vytvoření stránky, která umí operace select, insert, update a delete nad určitou tabulkou (či pohledem) v databázi. Jak bude konkrétně uživatelské rozhraní vypadat a z jakých částí se bude skládat, podle čeho bude možné třídit, filtrovat atd. je možné určit pomocí metadat, kterými odekorujete datový model z Linq To SQL nebo Entity Frameworku.
Jsou dvě možnosti, jak Dynamic Data použít – já jim říkám “odshora” anebo “odspoda”. První způsob se hodí pro rychlé naklikání informačního systému – hodíte tomu datový model a necháte si vygenerovat celou webovou aplikaci. Dostanete stránky pro manipulaci se všemi tabulkami a je to krásně provázané URL routingem. Pro praxi dost nevhodné, jelikož málokteré aplikaci tohle stačí.
Naštěstí je zde druhá možnost – aplikaci píšete tak, jak jste byli zvyklí doposud, akorát místo ručného určování a konfigurace sloupců u GridView či editačních formulářů u FormView tuto otročinu necháte udělat Dynamic Data pomocí zavolání jednoho příkazu v code-behindu.
Počáteční nadšení
Myšlenka této technologie se mi moc líbí. Když jsem před 10 lety psal v PHP, nejvíc mě štvalo, že validace musím psát na několika místech – v databázi, v PHP kódu aplikace a v Javascriptu, aby fungovala klientská validace, pokud to prohlížeč umí. Po přechodu na ASP.NET se částečně vyřešil problém psaní klientských skriptů – vestavěné validátory klientskou validaci generují samy a ty, které si píšu sám, většinou dělají věci, které se klientsky validují složitě, takže tam na ni kašlu. Pořád ale validujeme v databázi, pak v datovém modelu (který jsem v PHP nemíval) a pak ještě v UI, i když tam je to triviální pomocí přidání validátoru do stránky.
Vzhledem k tomu, že Dynamic Data validátory generují společně s UI (to, jestli je hodnota povinná nebo ne, se buď vykouká z toho, jestli sloupec v databázi povoluje hodnoty NULL, anebo se to dá vynutit atributem). V základu to umí i validace číselných polí. Pokud si trochu pohrajete, dají se nachystat šablony pro validaci data, času či e-mailové adresy, což pokryje většinu potřebných datových typů. Jsou zde poměrně široké možnosti, jak validace customizovat, v Linq To SQL je to velmi pěkně řešeno pomocí parciálních metod a validovat můžete jednotlivá pole při jejich změně, anebo celou entitu. Vše se propojí s validátory vygenerovanými přes Dynamic Data a funguje to.
Další věc, co mě vždy prudila, bylo psaní formulářů. Znáte to – tabulka, každý field jeden řádek, první sloupeček popis, druhý buď TextBox (to se ještě snese), DateTimePicker (moje vlastní komponenta, též v pohodě), anebo nějaký CheckBox. Horší to ale bylo, pokud je to výběr z nějakého číselníku nebo z navázané tabulky – to už je DataSource a ComboBox nebo něco podobného. A to je pruda.
ASP.NET Dynamic Data tohle všechno řeší, pokud v ddatabázi vidí asociaci (anebo pokud mi ji nahintujete atributem), vygeneruje samo ComboBox s výběrem položek. Vše se dá samozřejmě změnit, takže pokud máte objednávky a k nim vybíráte zákazníky, kterých je 10 000, nebudete uživatele nutit hledat je v seznamu, ale dáte mu tam nějakou jinou možnost (například Ajaxový modal popup s hledátkem). Vše se dá zařídit, stačí napsat vlastní field template, což pohříchu není vůbec těžké.
Pokud pravidelně sledujete můj Twitter, jistě jste si všimli, že jsem poslední měsíc na Dynamic Data dost nadával a kritizoval je. Jak to jde dohromady s výše uvedeným? To se dozvíte v další části tohoto blogpostu, která vyjde zítra.