V C# verze 2.0 se objevilo klíčové slovo yield, které je dle mého skromného názoru velmi mocné, ale co jsem si všiml, tak se netěší mezi vývojáři takové popularitě, jakou by si zasloužilo. Dost možná za to může mlha záhadnosti, která ho obestírá. Snad se mi podaří tímto článku onu mlhu rozkrýt – povíme si něco o yieldování v C#.
Celý příspěvek
Pozn.: V původním článku se vyskytovaly některé nepřesnosti, které mě vedly k revizi článku, který je ke shlédnutí zde. Z historických důvodů zde nechávám i tuto původní verzi.
Najít na internetu článek nebo dokonce seriál, který by se systematicky zabýval JavaScriptem, není nic jednoduchého – převažují články, které ukáží, jak deklarovat proměnné, v lepším případě funkce, poví něco o datových typech a tím to většinou končí. Navíc většina článků je mířena na použití JavaScriptu v rámci prohlížeče. Zřejmě i takovýto nedostatek informací vedl k tomu, že se z JavaScriptu stal jazyk, jenž je obestřen mnoha mýty, legendami a polopravdami, a mezi skutečnými programátory je značně neoblíben a/nebo nepochopen. Proto jsem se rozhodl sepsat tento článek, který představuje JavaScript z pohledu programátora, který je odkojen klasickými programovacími jazyky jako Pascal, C, C++, C# nebo Java. Představuje JavaScript (možná by se spíše slušelo říkat ECMAScript) jako univerzální jazyk, bez jakéhokoliv zaměření na nějakou konkrétní oblast nasazení (např. prohlížeče). Proč? Dnešní intenet je plný rich internet aplikací, jejichž výkonnost je často limitována rychlostí JavaScriptu a proto bylo v posledních letech vynaloženo mnoho úsilí na to, aby JavaScript běhal co nejrychleji. Proto lze očekávat nasazení JavaScriptu i v non-browser úlohách, např. se nabízí použití JavaScriptu na server-side záležitosti – pak by mohla být celá RIA napsána v jednom jediném jazyce.
V jednom z předchozích článků jsem popsal, jak téměř bezpracně zajistit perzistenci dat při přesměrování. Řešení bylo postavené na tom, že se hodnoty z ModelState uložily před přesměrováním do TempData (což je v drtivé většině případů de facto session). Hodnoty z formulářových polí se do ModelState dostanou během model-bindingu, tzn. že typicky máme ViewModel, který použijeme jako parametr action method, nebo voláme metodu [Try]UpdateModel. V popsaném případě se nám do ModelState uloží všechny hodnoty, které se měly možnost se nabidnovat na properties ViewModelu.
V předchozím příspěvku jsem ukázal, jak je možné pomocí návrhového vzoru Template Method zajistit správnou strukturu action method. Mé řešení sice funguje, ale na první pohled je kód dost nepřehledný – člověk vůbec nemá představu, k čemu ta která lambda slouží. Jak z toho ven?
Jednou z hlavních výhod, o kterých se mluví v souvislosti s MVC webovými frameworky, je to, že svým designem vedou vývojáře ke správnému rozvrstvení aplikace. Nejen začínající vývojáři ale občas umisťují něco tam, kam to nepatří, např. dávají moc logiky do views nebo (a to je asi nejtypičtější chyba) dávají aplikační logiku do controllerů. Podívejme se na to, jak je možné dále vést vývojáře ke správnému designu aplikace v rámci MVC frameworku, konkrétně ASP.NET MVC.
V tomto článku bych se rád podíval na to, jak je možné v ASP.NET MVC implementovat vzor Post-Redirect-Get. Ale proč se vůbec snažit o implementaci tohoto vzoru? Akademická odpověď by byla, že POST (stejně jako PUT a DELETE) HTTP metody jsou určeny pouze pro práci nad daty, nikoliv na prezentaci těchto dat, takže bychom měli vždy po POST, PUT a DELETE redirectovat na stránku, která prezentuje relevantní data. Praktické důvody, proč se následování tohoto vzoru v praxi vyplatí, jsou minimálně dva. Prvním je to, že uživatel v ideálním případě nikdy v adresním řádku prohlížeče neuvidí adresu, jejíž requestování by způsobilo operaci s daty. A protože ji neuvidí, nemůže si ji uložit do bookmarků ani poslat kamarádovi. Druhou výhodou tohoto nezobrazení adresy je zabránění vícenásobnému odeslání dat. Znáte to, stránka se načítá nějak pomalu, tak dáte F5, prohlížeč se zeptá, jestli odeslat data znovu, OK, a najednou jsem odeslal dva stejné posty do fóra, zaplatil dvakrát účet za telefon nebo koupil dvě auta 😉 Tak přesně tohle se nemůže nikdy stát, když budete ctít vzor PRG.
Jak je každému jasné, tak ASP.NET MVC je založeno na návrhovém vzoru Model-View-Controller. Rozebírat tady přímo tento vzor by bylo trošku kontraproduktivní, protože o něm již bylo napsáno mnoho. Zejména bych vypíchl výborné povídání o MVC na Zdrojáku. Zde bych se rád podíval na to, jak konkrétně je tento vzor implementován v ASP.NET MVC.
V tomto článku bych rád navázal na úvodní článek o validacích. Nejprve se podíváme na to, jakým způsobem vlastně vstupují data od uživatele do naší ASP.NET MVC aplikace, jak tato data validovat a nakonec to završíme tím, že si povíme o tom, jak o validačních chybách informovat uživatele.
Celý příspěvek
Všude tam, kde uživatel zadává nějaké údaje do aplikace, je potřeba tyto údaje před dalším zpracováním řádně zvalidovat, tedy ověřit jejich platnost (validitu). Je třeba si uvědomit, že validace existuje na různých úrovních. Pro účely tohoto článku nám bude stačit, když budeme rozlišovat mezi vstupní validací a business validací (více o validacích).
Celý příspěvek
Když jsem přecházel před lety z Delphi na C#, trošku mi chyběla možnost mít v metodě vnořenou funkci. Jasně, vždycky se to dá vyřešit tím, že se udělá další metoda, ale to už je další zbytečný kód navíc. Nejen, že si tím člověk zaplevelí třídu privátními metodami, které jsou velmi specifické a volají se jen z jedné metody, ale navíc musí do pomocné metody reprezentující vnořenou funkci předat kontext rodičovské metody, např. nějaké lokální proměnné nebo parametry.
Celý příspěvek
Augiho web 