V poslední době se hodně mluví a píše o moderních programovacích technikách (TDD, DDD) a o s nimi souvisejících technologiích. Mezi ně patří i poněkud konstrbatá zkratka IoC/DI – Inversion of Control/Dependency Injection, na kterou se podíváme v tomto článku. Předem podotýkám, že je článek některé skutečnosti zjednodušuje a slouží především jako úvod do problematiky.
Celý příspěvek
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. Článek představuje JavaScript jako univerzální jazyk, bez jakéhokoliv zaměření na nějakou konkrétní oblast nasazení (např. prohlížeče). Proč? Dnešní internet 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. Např. použití JavaScriptu v NoSql databázi CouchDB na psaní MapReduce funkcí je již realitou.
Sotva Microsoft uvolnil ASP.NET MVC 2, hned se na Codeplexu objevila roadmapa pro ASP.NET MVC, tedy takový nástřel, na co se bude tým dále soustředit. Vezměme si k ruce assembly ASP.NET MVC 2 Futures a podívejme se na to.
Celý příspěvek
Microsoft před pár dny uvolnil další verzi ASP.NET MVC, verzi 2. V době psaní článku je dostupná verze pro Visual Studio 2008. Verze pro 2010 jakoby nebude, protože ASP.NET MVC 2 bude dodáváno přímo s Visual Studiem 2010.
Ve verzi 2 není myslím nic, co by každého, kdo trošku sleduje scénu, překvapilo. ASP.NET MVC se totiž vyvíjí pod open source licencí Ms-PL, zdrojové kódy jsou dostupné na Codeplexu a tým vždy před releasem udělá několik pracovních verzí, díky čemuž má velmi dobrý feedback od komunity a ven jde dobře otestovaná věc.
Protože ale ne každý má čas/náladu/whatever sledovat průběžně novinky v ASP.NET MVC, podíváme se v tomto článku na zoubek novinkám ve verzi 2 (vůči verzi 1).
Celý příspěvek
Na dnešním internetu je důležité, aby url měly ten správný tvar, a díky tomu je do jisté míry můžeme považovat za součást prezentační vrstvy. Určitě ale nechceme, aby nějaké stringy z prezentační vrstvy ovlivňovaly to, jak se budou jmenovat naše třídy nebo metody v aplikaci. Ale právě přesně to se v ASP.NET MVC děje – adresa ve tvaru „/controllerName/actionName“ je typicky mapována na akční metodu s názvem „actionName“ ve třídě „controllerNameController“. No ale kdo by chtěl mít metodu s názvem „追加する“? A co na to lokalizace?
Celý příspěvek
Pokud se snažíte v C# psát aplikace modulárně a genericky, tak můžete narazit na to, co je naznačeno v nadpisu – vytváření instancí tříd, jejichž typ není v době kompilace znám. Jak na to si ukážeme v tomto článku, včetně porovnání výkonu. Konkrétně se zaměřím na vytváření instancí pomocí bezparametrického konstruktoru a příliš nebudu řešit to, kolik zabere příprava té které metody instanciace – jde mi o vytváření velkého množství instancí malého počtu tříd.
Celý příspěvek
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?
Augiho web 