IIS Developer Express

Když člověk dosud vyvíjel v ASP.NET, měl prakticky jen dvě možnosti, jak svou aplikaci otestovat – použít webový server vestavěný ve Visual Studiu (ASP.NET Development Server zvaný také Cassini) nebo použít lokální IIS Web Server. Nevýhodou první možnosti je to, že nemáme k dispozici vše, co v plném IIS, a tak ladíme v jiném prostředí, než kde budeme aplikaci provozovat.
Nevýhodou použití IIS je to, že jeho verze je spjatá s verzí operačního systému vývojářského stroje (takže opět jiné prostředí pro vývoj a pro nasazení).
Proto Microsoft přišel s IIS Developer Express, které spojuje výhody velkého IIS 7.x (obsahuje tedy všechny jeho fičury, včetně SSL nebo URL Rewrite, a to na všech Windows od XP výše včetně) a lehkost Cassini, tj. xcopy distribuce (není třeba nic instalovat/registrovat), nejsou třeba administrátorská práva a použití (včetně integrace do Visual Studia) je jednoduché a intuitivní. Nainstalovat si ho můžete přes Web Platform Installer.
Podrobnosti v článku Scotta Guthrieho.

SQL Server Compact Edition 4

Jedná se o novou verzi embedded relační databáze. Její výhodou je žádná instalace, takže i pokud máte k dispozici jen sdílený hosting, není to problém – stačí do bin adresáře nakopírovat binárky. Další zásadní vlastností je to, že databáze podporuje (dosti velký) subset jazyka Transact-SQL (používaný ve velkém SQL Serveru) a je možné použít nejen klasický ADO.NET přístup, ale i další oblíbené O/R mappery. Důležité je také to, že tento produkt (stejně jako IIS Developer Express) je zdarma.
Zajímavostí (značně užitečnou) je přítomnost podpory pro stránkování přímo v této verzi T-SQL – přes příkazy OFFSET a FETCH – takže není nutné používat ranking functions. Více detailů najdete v tomto blogspotu.

Razor

Razor je nový templatovací engine, tedy něco jako dosavadní (ne-příliš oblíbený) T4. Zjednodušeně řešeno je to třída, do které strčíme data a šablonu a jako výsledek dostaneme string (data přetransformovaná šablonou).
Pro webové vývojáře je zajímavý tím, že bude použit jako alternativa ke stávajícím WebForms stránkám (typicky soubory s příponou aspx), což se vzhledem k méně zašumněné syntaxi hodí; ale není to žádný přelomový krok. Soubory mají příponu cshthml nebo vbhtml, podle jazyka, který používáme uvnitř šablony (C# nebo VB.NET), a říká se jim ASP.NET Web Pages.
Připravuje se také nový view-engine pro ASP.NET MVC, který bude založen právě na Razoru. Btw. prvního preview ASP.NET MVC 3 bychom se měli podle jednoho komentáře na blogu Scotta Guthrieho dočkat již v průběhu tohoto měsíce (červenec 2010).
Poměrně podrobný popis syntaxe najdete kde jinde než v článku Scotta Guthrieho.

WebMatrix

WebMatrix je free vývojové prostředí pro tvorbu jednoduchých webů. Je postavené na ASP.NET Web Pages (jednoduchý framework nad ASP.NET), který využívá výše zmíněného Razoru pro zápis “dynamického” kódu v tzv. spaghetti stylu (jedna dlouhá nudle). Není to tedy nic pro profi vývojáře, je mířeno spíše na začátečníky a hobby vývojáře. Pokud bude vývojáři WebMatrix těsný, je možné projekt překlopit do verze pro Visual Studio. I zde najde začátečník či hobby vývojář free vývojové prostředí – Visual Web Developer 2010.
Z prostředí WebMatrixu je možné ovládat také IIS Developer Express a SQL Server Compact Edition (které se instalují spolu s WebMatrixem), takže vývojář má k dispozici kompletní free webový stack pro vývoj.
Úvod do WebMatrixu najdete zde, podrobnější informace např. na webu asp.net.

Visual Studio 2010 v češtině

Nevím jaky Vy, ale já jsem odpůrcem lokalizace vývojových nástrojů. Angličtina prostě k vývojařině patří a alespoň základy by tak měl umět každý, kdo to myslí s programováním vážně. Lokalizačaní balíček pro Visual Studio 2010 je možné nainstalovat do Visual Studia minimálně verze Professional – to je dle mého skromného názoru způsobeno tím, že Express edice nepodporují addony. Nicméně pokud má být lokalizace určena především pro edukativní účely, není to myslím problém, protože většina “IT škol” je v programu MSDN AA, příp. studenti mohou využít programu DreamSpark.

I can never say that I will not change the used IoC/DI container (e.g. when I would want to use some heavy Unity features or separate file configuration) so I decided that my container will implement the ServiceLocatorImplBase abstract class from CommonServiceLocator library. So I had to implement two methods – DoGetInstance and DoGetAllInstances. Implementing of this abstract class ensures that I will use one interface (from CommonServiceLocator) in whole application (except registrations). And so if I want to use some other IoC/DI container then I would change types registration only (because it’s always container specific). The rest of application wouldn’t require changes.

The storage

What does container do? It maps type to some instance. So let’s start with this storage:

Dictionary<Type, Func<Type, object>> _Registrations;

We map Type to delegate. The delegate has one parameter (Type) and returns instance of this type. So we map type to method that obtains type instance. The method can just call parameterless constructor or it can be something more sophisticated. We are not limited when writing this method – it’s a regular method.
The DoGetInstance method has actually two parameters – Type and string (key). So we have to add one mapping to our storage and one parameter to our delegate:

Dictionary<Type, Dictionary<string, Func<Type, string, object>>> _Registrations;

Actually, it could be handy to have access to container from creating method so I add one more parameter to the delegate:

Dictionary<Type, Dictionary<string, Func<SimpleContainer, Type, string, object>>> _Registrations;

And that’s all! We are now able to store all data we need.

Methods

Next, we have to implement DoGetInstance method. It’s very straightforward:

protected override object DoGetInstance(Type serviceType, string key)
{
	var creators = _Registrations[serviceType]; // map type
	if (creators != null && creators.Count > 0)
	{
		Func<SimpleContainer, Type, string, object> creator;
		if (string.IsNullOrEmpty(key) || !creators.TryGetValue(key, out creator) || creator == null) // try to map key
		{
			// use empty key as fallback
			creators.TryGetValue(string.Empty, out creator);
		}
		if (creator != null)
		{
			return creator(this, serviceType, key);
		}
	}
	throw new ActivationException(string.Format("Creator for '{0}' for key '{1}' not found.", serviceType, key));
}

Next, we have to implement some method that will register method for type instance obtaining:

public void Register(Type serviceType, string key, Func<SimpleContainer, Type, string, object> creator)
{
	Dictionary<string, Func<SimpleContainer, Type, string, object>> creators;
	if (!_Registrations.TryGetValue(serviceType, out creators))
	{
		_TypeToCreators.Add(serviceType, creators = new Dictionary<string, Func<SimpleContainer, Type, string, object>>(StringComparer.OrdinalIgnoreCase));
	}
	creators[key ?? string.Empty] = creator;
}

Very easy, I think. And that’s all! We now have IoC container that is able to handle most of our requirements. Don’t you believe me? Let’s implement some supporting extensions methods that handle common scenarios.
Before we start I would like to notice that I implemented DoGetAllInstances abstract method in very similar way too. And I added common IDisposable pattern into our container too (check source code download at the end of this article).

Basic overloads

I really like strong typed languages and so I like generics. Let’s implement generic Register method:

public static void Register<T>(this SimpleContainer container, string key, Func<SimpleContainer, Type, string, object> creator)
{
	container.Register(typeof(T), key, creator);
}

Our container should be able to serve singleton for us:

public static void RegisterInstance<T>(this SimpleContainer container, string key, T instance)
{
	// we store instance reference in scope of lambda function bellow
	container.Register(typeof(T), key, (c, t, k) => instance);
}

Do you want to dispose singleton at the end of program (more exactly – when container is disposing) ?

public static void RegisterSingleton<T>(this SimpleContainer container, string key, T instance)
{
	var asIDisposable = instance as IDisposable;
	if (asIDisposable != null)
	{
		container.Disposing += (sender, eventArgs) => asIDisposable.Dispose();
	}
	container.Register(typeof(T), key, (c, t, k) => instance);
}

Dependency injection

Well, we have very handy and lightweight container but it is not IoC/DI container – we don’t manage dependency injection at all. If we want to use dependency injection then we can do that by hand:

container.Register<IMyInterface>((c, t, k) => new MyInterfaceImplementation(
	c.GetInstance<ISomeOtherInterface>(),
	c.GetInstance<IDifferentInterface>()));

Our MyInterfaceImplementation class has constructor with two parameters and we have to resolve these parameters when we are constructing the object. So we just delegate this task recursively to container. Pretty cool!
But programmers (including me) are too lazy and so we want to simplify this very common task:

public static void Register<T, TImplementation>(this SimpleContainer container, string key)
{
	var ctors = type.GetConstructors();
	if (ctors == null || ctors.Length == 0)
	{
		throw new ActivationException(string.Format("Appropriate constructor not found in type '{0}'.", type));
	}
	var ctor = ctors[0];

	var containerParameter = Expression.Parameter(typeof(SimpleContainer), "container");
	var typeParameter = Expression.Parameter(typeof(Type), "type");
	var keyParameter = Expression.Parameter(typeof(string), "key");

	var creator = Expression.Lambda(typeof(Func<SimpleContainer, Type, string, object>),
		Expression.New(ctor,
			// ctor parameters
			ctor.GetParameters().Select(p => (Expression)Expression.Call(containerParameter, "GetInstance", new[] { p.ParameterType }))),
		containerParameter, typeParameter, keyParameter); // lambda parameters
	return (Func<SimpleContainer, Type, string, object>)creator.Compile();
}

This may look difficult but it’s very easy – we construct lambda expression that invokes constructor and supplies constructor parameters via container.GetInstance method call. Just the same that we did by hand.

Registration overriding

We usually use one main container but sometimes we could want to change resolving for some specific types. Then we can use containers hierarchy that handles registration overriding.
We have to add ParentContainer property (e.g. of type SimpleContainer) to our SimpleContainer class. Then we create two extension methods:

public static SimpleContainer CreatePermanentChildContainer(this SimpleContainer container)
{
	return new SimpleContainer { ParentContainer = container };
}

public static SimpleContainer CreateChildContainer(this SimpleContainer container)
{
	var child = container.CreatePermanentChildContainer();
	container.Disposing += (sender, eventArgs) => child.Dispose();
	return child;
}

We can use these extension method to implement very handy method:

public static void RegisterWithOverride<T>(this SimpleContainer container, string key, Func<SimpleContainer, Type, string, object> creator, Action<SimpleContainer> overrideContainer)
{
	container.Register<T>(key, (c, t, k) =>
	{
		using (var cc = container.CreatePermanentChildContainer())
		{
			overrideContainer(cc);
			return creator(cc, t, k);
		}
	});
}

Our new method has one more parameter – overrideContainer that is aimed for registration overrides.
And finally, we can use this pretty cool extension method:

// most of classes will use ServiceOne for IMyService
container.Register<IMyService, ServiceOne>();
// but IMyInterface will use ServiceTwo for IMyService
container.RegisterWithOverride<IMyInterface, MyInterfaceImplementation>(cc =>
	{
		cc.Register<IMyService, ServiceTwo>();
	});

Summary

As you can see, implementation of own lightweight IoC/DI can be very easy. It could be probably better to use some good known IoC/DI container in large enterprise application but if your requirements aren’t very high, you don’t need registration via external configuration file (so registration in code is sufficient) and you want to have good performance then own lightweight IoC/DI container can be good solution.
I created project SimpleContainer on CodePlex and so you can download source codes here. You can let me know if you (don’t) like that and/or use that.
I implemented extensions method for registering instance for one web-request too. It uses own implementation of IHttpModule so if you want to use this feature then you have to register this module in your web.config.
Footnote: I discovered that there are some light IoC/DI containers for .NET: Funq and Munq. But these containers are much more complicated – remember that SimpleContainer core is just one class and the second class contains set of extension methods only.

V čem byste implementovali úložiště dat, aby bylo opravdu rychlé? C/C++? Asm? Některá NOSQL úložiště jdou touto cestou (např. MongoDB), ale Cassandra a HBase jsou implementovány v Javě. Ano, v tom strašné, pomalém a zdroježeroucím molochu, jak by Javu mnozí počastovali. Ale vězte, že na tomto molochu běží celý internet…tedy, ehm, Facebook Cassandra je totiž zopensourcovatělé jádro Facebooku, ale dnes ji používá i Twitter a další služby.
Implementace v Javě určila i ekosystém okolo těchto úložišť, takže prakticky všechny nástroje a knihovny okolo jsou také implementovány v Javě. A zde vyvstává otázka jak komunikovat s úložištěm z .NETu. Protože celá komunikace probíhá přes síť, není to nic složitého. Mnozí by očekávali nějaký známý protokol jako SOAP nebo OData, ale Cassandra i HBase používají (IMHO mezi .NET komunitou zcela neznámý) Thrift.

Thrift je síťový binární protokol pro RPC, který je ale i přes svou binárnost otevřený k rozšíření (není nutné se vázat na jednu verzi služby). Thrift ale není jen definice protokolu. Thrift dále přináší vlastní IDL (jazyk pro popis rozhraní služby), který umí dodávané nástroje transformovat do mnoha jazyků (C# nevyjímaje). Takže spolu s Cassandrou si stáhneme Thrift API a z toho si nagenerujeme klientské třídy v C#. Je to tedy stejný postup, jako když z WSDL generujeme třídy pro komunikace přes SOAP.

API Cassandry není moc bohaté a vlastně nám umožňuje jen vybírat hodnoty podle klíčů a hodnoty ukládat. Více v dokumentaci.

Datový model

Nejvyšší úrovní dělení je tzv. KeySpace (~databáze), který obsahuje ColumnFamilies (~tabulky). Každá ColumnFamily obsahuje řádky, které jsou identifikovány pomocí klíče. Každý řádek může obsahovat libovolný počet sloupců. Každý sloupec (identifikovaný jménem) má přiřazenu hodnotu a timestamp (který dodává aplikace!). Hodnotou sloupce nemusí být jen byte[], ale opět to může být další Mapa – pak mluvíme o tzv. SuperColumn.
Datový model pro programátory:
Map<byte[], Map<byte[], Map<byte[], Tuple<byte[], TimeStamp>>>>.
Neboli:

• KeySpace name (typicky string) -> ColumnFamilies
• ColumnFamily name (typicky string) -> Rows
• Row key (byte[]) -> Columns
• Column name (string) -> ColumnValue (byte[], timestamp)

Často se datový model vysvětluje (a je to tak přesnější) tak, že se obrátí ColumnFamily a řádek, tedy že řádek obsahuje ColumnFamilies.
Důležité je, že v konfiguraci se nastavují pouze KeySpaces a ColumnFamilies. Všechno ostatní je variabilní a může se to měnit – a to na každé úrovni. To mj. znamená, že každý řádek může mít libovolný počet sloupců a u každého řádku mohou být sloupce úplně jiné.
Data jsou fyzicky setříděná podle klíčů a sloupce také seřazeny podle názvů. Protože se všude pracuje s blobama byte[], máme možnost definovat, jakým způsobem se má třídit.

Velmi pěkný popis datového modelu Cassandry naleznete v tomto článku.

Jak jsem psal, Cassandří API je poměrně jednoduché a tak Vás možná napadne, že vybírání hodnot jen podle klíčů není dostatečné. A je to možné! Opravdu Vaše aplikace nemusí být vůbec vhodná pro nasazení na NOSQL úložišti. Ale i tak je vybírání podle klíčů poněkud svazující a proto byla ve verzi Cassandry 0.6 přidána podpora pro Hadoop.

Hadoop

Hadoop je v Javě napsaný open-source framework pro psaní spolehlivých, škálovatelných a distribuovaných výpočtů. Sestává se z několik částí, přičemž nás bude zajímat hlavně MapReduce, což je implementace MapReduce algoritmu. To je zjednodušeně řečeno algoritmus, který nám umožní položit dotazy, které se dají snadno paralelizovat.
Tento Map/Reduce se pak typicky využívá nad NOSQL úložištěm HBase (další část Hadoopu), které je postavené nad distribuovaným file systémem HDFS (také součást Hadoopu).

Když chceme zadat nějakou Map/Reduce úlohu, musíme předat do jobtrackeru jar, který obsahuje třídy implementující rozhraní Mapper a Reducer.
Pokud chceme dělat něco jednoduchého a nechce se nám kódit v Javě, můžeme použít Hadoop Streaming, což není nic jiného než konkrétní implementace Mapperu a Reduceru, která volá námi zadaný program a komunikuje s ním přes stdin/stdout. Konkrétně to funguje tak, že do Mapperu, resp. Reduceru, přichází řádky oddělené znakem nového řádku. Na řádku je nejprve klíč následovaný tabulátorem. Zbytek do konce řádku je hodnota.
Na jednoduché věci to určitě stačí, ale pokud chceme absolutní svobodu, pak musíme sáhnout po Hadoop Pipes. Jeho základem je opět implementace Mapperu a Reduceru, která tentokrát volá tenký wrapper v C++ (přes sockety). S tímto wrapperem je už možné komunikovat z téměř jakéhokoliv jazyka, protože je pro něj dostupné SWIG rozhraní (něco jako Thrift, ale funguje to lokálně). Takže díky tomuto můžeme psát Map/Reduce funkce v jakém jazyce chceme.

Psaní Map/Reduce dotazů se nám může ale pěkně zkomplikovat, zvláště když dotazy vyžadují více iterací. Pak můžeme sáhnout po projektu Pig (součást Hadoopu), který nám umožní zapsat dotazy v jazyce Pig Latin (ne nepodobný Linqu). Pig Front-end zadaný dotaz naparsuje, zoptimalizuje a vytvoří LogicalPlan, který popisuje, jak by se měl daný skript spustit. O samotné vykonání se pak postará Pig Back-end. Nyní existují dvě implementace Pig Back-endu – nad lokálním úložištěm (méně zajímavé) a nad Map/Reduce (obsahuje imlementaci Mapperu a Reduceru).
Abychom tedy mohli napsat Map/Reduce dotaz, nemusíme tedy nutně psát kód v Javě, ale místo toho předáme jen string obsahující skript v jazyce Pig Latin.

Podobný účel jako Pig má také projekt Hive, který přináší ještě vyšší stupeň abstrakce a umožňuje dotazovat do libovolného úložiště (pomocí jazyka QL), jehož strukturu jsme schopni popsat (musíme tedy zavést nad úložištěm strukturu). Hivem se ale nebudu teď zabývat, protože ještě není v production quality.

Shrnutí

Jak tedy pracovat s Cassandrou z .NET? Pokud si vystačíme s API, které nám nabízí Cassandří Thrift, pak si stačí nagenerovat třídy pro C# a máme vystaráno. Pokud Vám připadá Thriftové rozhraní příliš low-level, jsou k dispozici i nějaké nadstavby (třeba connection pooling je dobrý nápad).

Pokud chceme provádět Map/Reduce operace, je situace složitější, protože v jádru jde vždy o Javu.
Můžeme mít např. jednoduchou web-service, do které budeme posílat jary s Mapperem a Reducerem. Nebo můžeme mít na serveru předpřipravené jary a modifikovat soubor s parametry uložený uvnitř nich (je to jen zip).
Další možností je posílat do naší webové služby pouze dotazy v jazyce Pig Latin – pak už jsme blízko klasické situaci, kdy na SQL server posíláme dotazy v SQL.

Pokud se někdo rozhodne nasadit Cassandru na svůj projekt, měl by se nejprve důkladně obeznámit s jejím datovým modelem a zjistit, jestli bude mít k dispozici věci, které potřebuje a třeba je považuje za samozřejmost (díky SQL světu). Není to všespásný zlatý grál a nehodí se na všechny typy projektů.

Třívrstvá architektura

Po dlouhá léta byla standardem pro dobře navrženou aplikaci (aspoň já jsem to tak vnímal) klasická třívrstvá architektura, kterou má téměř každý vývojář tak nějak zažitou.

Podívejme se blíže na závislosti, které máme mezi jednotlivými vrstvami. Prezentační vrstva je závislá na business vrstvě. To je legitimní závislost, protože by nám ve většině případů neměl návrh uživatelského rozhraní zásadně ovlivňovat business vrstvu. Proč? Například kvůli možnosti zavedení nové prezentační vrstvy. Závislost tímto směrem a striktní oddělení nám tedy umožňuje snadno vyvinout novou prezentační vrstvu (např. vedle webového rozhraní budeme chtít s naší aplikací komunikovat také přes webové služby).

Druhá šipka nám říká, že business vrstva je závislá na přístupu k datům. I toto má zdánlivě svou logiku…ale je opravdu způsob uložení dat ta nejdůležitější část naší aplikace? Není srdcem naší aplikace spíše business logika? Často ano! A tím jsme právě vyslovili jednu ze základních myšlenek Domain Driven Design (tím se ale zatím zaobírat nebudu). Protože je tedy business logika to nejdůležitější, proč by měla záviset na přístupu k datům, proč by se měla přizpůsobovat? Ať se radši přizpůsobí DAL! Obraťme tedy zmiňovanou závislost.

Pokud Vás předchozí odstavec nepřesvědčil, že by mohlo být vhodné obrátit závislost mezi BL a DAL, přistupme k situaci praktičtěji.
DAL neví zhola nic o naší business vrstvě. Je to tedy nějaká víceméně univerzální knihovna pro přístup k datům. Když pracujeme třeba s nějakou relační databází a chceme udělat nějaký krutopřísně rychlý dotaz, občas se nevyhneme tomu, že jsme nuceni napsat třeba nějaký specifický SQL dotaz. A kam ho zapíšeme? No přece do business logiky! Do DAL ho zapsat nemůžeme, protože ten přece o BL nic neví – DAL je univerzální knihovna, kterou používáme klidně ve více nesouvisejících projektech. Takže abychom dosáhli lepšího výkonu, máme nějaký specifický SQL dotaz v BL – nesmrdí Vám to? Nechtělo by to přehodnotit návrh (závislosti) ?
Dalším argumentem pro obrácení závislosti může být to, že ve stávajícícm návrhu nejsme schopni jednoduše vyměnit DAL. Aplikace totiž přistupuje pouze k BL a nemá nad DAL kontrolu (ten je skryt za BL). Jednoduchá výměna DAL se nám může hodit nejen v případě migrace na jiné úložiště, ale také v případě psaní unit testů.

Jiný pohled

Pokud člověk ve firmě vyvíjí jedinou aplikaci a nemá tak potřebu sdílet DAL mezi nesouvisejícími aplikacemi, tak už možná tuto závislost obrátil, protože DAL přizpůsobil business layeru a dopsal do něj (do DALu) nějaký ten krutopřísný specifický dotaz. Je dobré si uvědomit, že tímto je zavedena závislost DALu na BL. A pokud nemáme interface DALu oddělený od implementace, tak tu máme krásnou kruhovou závislost – DAL je přizpůsoben na míru BL a BL používá konkrétní implementaci DALu. Jinými slovy, jeden bez druhého nemůže existovat a z jistého pohledu máme provázánou business vrstvu a konkrétní přístup k datům.

Obraťme tedy závislost mezi BL a DAL (který jsem přejmenoval na Persistence) a koukněme se, co z toho pro nás vyplývá – především to, že si BL může diktovat, jak má vypadat vrstva Persistence. V praxi to znamená, že Persistence nyní nemusí být (jako DAL) obecná knihovna pro přístup k datům (ale může z takové knihovny vycházet!), ale je to knihovna, která posluhuje BL a přizpůsobuje se jí. Rozhraní IPersistence tedy může vypadat třeba nějak takto:

public interface IBlogPersistence
{
  IEnumerable<Article> GetArticles();
  void AddArticle(Article article);
  void UpdateArticle(Article article);
  void RemoveArticle(Article article);
  IEnumerable<Comment> GetArticleComments(Article article);
  IEnumerable<Article> GetArticlesWithComments();
}

Jak vidno, toto není rozhraní univerzální knihovny pro přístup k datům. Nějaká knihovna pro přístup k datům (třeba Entity Framework, Linq2Sql, NHibernate, …) ale může být použita pro implementaci výše uvedených metod. To už je ale implementační detail, který je skryt za rozhraním.
Je zřejmé, že nyní můžeme ve vrstvě Persistence pěkně tunit třeba svoje SQL dotazy bez toho, aniž bychom si zašpinili BL. BL totiž zná pouze interface vrstvy Persistence.
Jedním z prvků SOLIDní architektury je Open/closed princip (btw. verze v katalánštině ), který říká, že rozhraní by mělo být otevřené k rozšíření ale uzavřené ke změnám. Pokud je tedy předpoklad, že se budou požadavky na Persistence měnit a museli bychom tedy měnit interface IPersistence (přidávat metody), může být vhodné použít nějaký přístup, který nám umožní psát další dotazy proti Persistence aniž bychom měnili jeho interface. Toto řeší tzv. doménové dotazy, což je tedy způsob, jak se dostatečně obecně dotazovat do Persistence (jak mu předat dotaz). Když chceme implementovat doménové dotazy, můžeme vytvořit třeba množinu tříd, které pro nás dostatečně popíšou požadované dotazy. Zde může být dobrým nápadem použít něco již existujícího, třeba Linq. Ano, mířím tím k tomu, že dobrou výchozí implementací Persistence může být DataContext z Linq2Sql nebo ObjectContext z Entity Frameworku. Avšak mysleme stále na to, že tyto konkrétní frameworky jsou jen implementační detail, který je skryt kdesi v hloubi implementace IPersistence.
Jen bych dodal, že Linqem se nikterak neomezujeme jen na relační databáze nebo dokonce jen na Ms Sql – pomocí Linqu se lze dotazovat do CSV souborů, do leckterých NOSQL databází nebo do čeho chceme – nikdo nám nebrání nepsat si vlastní Linq provider. Omezujeme se tedy jen na to, že persistentní vrstva si musí umět poradit s Linqem (příp. jeho podmnožinou).

Implementace závislostí

Pro lepší pochopení zde přikládám diagram, který znázorňuje celou architekturu aplikace.

Jádrem naší aplikace jsou tedy nějaké business objekty, které se nějak persistují pomocí rozhraní IPersistence – to je jedna assembly. Důležité je, že o použité implementaci IPersistence nerozhoduje BL (protože ta ani žádnou implementaci nezná), ale konkrétní implementaci musíme do BL nějak dodat (injektovat) při použití z aplikace – např. přes parametr konstruktoru.
Dále je třeba rozhraní IPersistence někde implementovat. Můžeme mít třeba dvě implementace (ve dvou různých assembly) – MsSqlPersistence (pracuje proti MS Sql) a MockPersistence (pro účely unit testů).

Když pak máme nějakou aplikaci (třeba webové GUI), tak si musíme v Controlleru/Presenteru vytvořit instanci BL, tzn. musíme to něj strčit (injektnout) nějakou konkrétní implementaci IPersistence a pak už můžeme s BL vesele pracovat (a BL používá nainjectovanou implementaci IPersistence).
Slovem injektnout v předchozích větách jsem se snažil naznačit, že může být velmi vhodné mít závislosti vyřešené přes Dependency Injection. Pak nám stačí při startu webové aplikace nakonfigurovat kontejner tak, aby nám pro rozhraní IPersistence vracel instanci třídy MsSqlPersistence (v unit testech obdobně) – pak se nám kontejner sám postará o to, že při vytváření instance BL nám do něj přes konstruktor nainjectuje nakonfigurovanou implementaci rozhraní IPersistence.

Závěr

Zde prezentovaná architektura aplikace jistě není ideální a nemusí být ani vhodná pro každou aplikaci, ale myslím, že je lepší než klasický třívrstvý návrh. Rozhodně by si zasloužila další vylepšení, ale to by bylo na mnoho dalších článků. Proto tento článek neberte jako dogma a finální řešení, jak se mají dělat aplikace – berte ho jako návod na možné řešení problémů, se kterými se můžete ve Vaší aplikaci setkat.
V případných dalších článcích by se rád posunul v návrhu dále, konkrétně trošku směrem k DDD. Úmyslně jsem tu nechtěl hned vybalit DDD, protože se jedná o poměrně rozsáhlou záležitost plnou nových pojmů a myšlenek, které jsem ještě ne zcela vstřebal a přijal za své (co jsem četl, tak 3 roky studia a aplikace DDD na 3 projektech je dobrý základ pro základní pochopení DDD) a proto si netroufám v tomto směru zatím dále edukovat. Cílem článku je pouze ukázat čtenáři jinou cestu a trošku se zamyslet nad dogmatem klasické třívrstvé architektury aplikace (která nemusí být v každé situaci vhodná).

Inversion of Control

Vzpomínám si, že už před lety jsem někde četl, že by se mělo programovat proti interfacům, ne proti konkrétním třídám. Inversion of Control myšlenku programování proti rozhraním mohutně používá a v jistých ohledech dotahuje do konce. V případě IoC de facto nevytváříme aplikaci jako monolit, ale jako sadu komponent, které implementují různá rozhraní. Tyto komponenty s okolním světem opět komunikují opět pouze pomocí rozhraní, bez závislosti na konkrétních implementacích. Komponenta tak řeší opravdu jen svoje problémy, nestará se o okolní komponenty.
Aplikaci pak vdechneme život tím, že určíme, jak propojit komponenty do fungující aplikace.
Rozbití aplikace na komponenty (rozhraní), jejichž konkrétní implementace (třídy) lze jednoduše vyměnit, je velmi užitečná vlastnost. Můžeme díky tomu jednoduše sestavit více podobných aplikací, které se liší např. tím, odkud načítají data (MySql, MsSql, soubor, webová služba, …). V případě testování je pak snadná výměna komponent aplikace k nezaplacení.

Klíčové je, že pracujeme s rozhraními a téměř nikde by se tak nemělo vyskytovat klíčové slovo new, protože tím bychom se fixovali na nějakou konkrétní implementaci. S IoC tento úkol delegujeme na tzv. IoC kontejner. To je třída, která ví, jak získat instanci třídy, která implementuje dané rozhraní. Rozhraní IoC kontejneru může tedy vypadat nějak takto:

public interface IIoCContainer
{
  TService GetInstance<TService>();
}

Takže místo ICar c = new Car() nyní voláme třeba ICar c = OurContainer.Current.GetInstance<ICar>().

Různé IoC kontejnery ale mají různá rozhraní a proto by případný přechod na jiný (lepší) IoC kontejner znamenal v lepším případě udělat replace přes celý projekt (např. “OurContainer.Current.GetInstance” -> “BetterContainer.Instance.GetNewInstance“). To je samozřejmě fuj, ale problém řeší projekt CommonServiceLocator, který přináší jednotné rozhraní pro nejrozšířenější IoC kontejnery. Ono rozhraní má sice více metod, ale de facto se jedná jen o overloady metody GetInstance z výše uvedeného rozhraní – podívejte se sami. Btw. CommonServiceLocator se tak jmenuje proto, že se jedná o implementaci návrhového vzoru Service locator, což je takový centrální bod aplikace.

Kontejner je třeba (typicky na začátku programu, při startu webové aplikace apod.) patřičně nakonfigurovat, aby věděl, jak získávat implementace požadovaných rozhraní. Každý IoC kontejner má různé možnosti konfigurace a vytvoření jednotného rozhraní pro konfiguraci by znamenalo, že se zbytečně omezíme (protože hledáme průnik). Ale k vytvoření jednotného rozhraní pro konfiguraci kontejneru ani není motivace – konfigurace je totiž obvykle jen v pár souborech, takže není takový problém ji přepsat.
Syntaxe konfigurace je tedy pro každý IoC kontejner unikátní a bývá uvedena buď v kódu nebo v nějakém konfiguračním souboru. Konfigurace kontejneru v kódu může vypadat např. takto:

myContainer.Register<ICar, Car>();

Tady říkáme, že pokud někdo bude chtít rozhraní ICar, má se použít třída Car.

V praxi se setkáváme s různými požadavky na životnost objektů – vždy nechceme, aby nám metoda GetInstance vrátila novou instanci. Např. můžeme chtít, aby ve webové aplikaci objekt žil po celou dobu jednoho požadavku, tedy aby metoda GetInstance vracela v průběhu jednoho požadavku stále tutéž instanci. Nebo můžeme chtít, aby se vracela tatáž instance v průběhu celého programu (tedy singleton). Všechno tohle kvalitní IoC kontejnery umí. Základem je ale schopnost konfigurace a získání instance implementující dané rozhraní.

Dependency Injection

IoC kontejner většinou funguje tak, jak jsem popsal – řekneme mu, jaká třída implementuje jaké rozhraní (což by si btw. mohl zjistit pomocí reflexe sám, ale to může vést na nejednoznačnosti). Většinou ale explicitně neříkáme, jak konkrétně se má daná třída vytvořit – s tím se musí kontejner nějak vypořádat sám. Pokud by Vás zajímalo, co se může dít uvnitř, mrkněte na můj článek o vytváření instancí v době kompilace (v době kompilace IoC kontejneru!) neznámých typů za běhu.
Pokud má třída bezparametrický konstruktor, tak je to úloha poměrně snadná. Ale co když má konstruktor nějaké parametry? Pak přichází ke slovu tzv. constructor injection. Kontejner si zjistí, jaké parametry jakých typů konstruktor má. Konkrétní hodnoty parametrů pak získá tak, že “zavolá GetInstance<TParameter> sám na sebe”. Pak již nic nebrání tomu zavolat konstruktor se správnými parametry.
Dále se používá ještě setter injection, kdy se IoC kontejner postará po vytvoření objektu ještě o přiřazení správné hodnoty do property, která má public setter (a samozřejmě i nějaký getter).

Praxe

Dejme tomu, že máme auto, které má motor, a chceme nastartovat nějaké auto s nějakým motorem:

public interface IEngine
{
  void Start();
}

public interface ICar
{
}

public class Engine : IEngine
{
  public void Start()
  {
    Console.WriteLine("engine started");
  }
}

public class Car : ICar
{
  public Car(IEngine engine)
  {
     engine.Start();
  }
}

public static class Bootstrapper
{
  public static void Run()
  {
    // vytvoreni kontejneru
    var container = new OurContainer();

    // propojeni naseho IoC kontejneru na Service locator
	// using Microsoft.Practices.ServiceLocation;
    ServiceLocator.SetLocatorProvider(c => container);

    container.Register<ICar, Car>();
    container.Register<IEngine, Engine>();
  }
}

public static class Application
{
  public static void Main()
  {
    Bootstrapper.Run(); // konfigurace

    // kontejner vi, ze ma pouzit tridu Car
    // take vi, ze rozhrani IEngine implementuje trida Engine
	// using Microsoft.Practices.ServiceLocation;
    ICar c = ServiceLocator.Current.GetInstance<ICar>();
  }
}

Je to velmi jednoduché – registraci provedeme pomocí metody Register, získání instance pak pomocí metody GetInstance.

V praxi je na výběr z mnoha IoC/DI kontejnerů. Mezi nejznámější patří Unity (přímo od Microsoftu), Microkernel a Windsor Container od Castle, Spring.NET, StructureMap, Autofac, Ninject, PicoContainer.NET…
Ale není nic extrémně složitého vytvořit si vlastní jednoduchý IoC(/DI) kontejner, takže pojďme na to:

public class OurContainer
{
  // mapovani z typu (nejcasteji rozhrani) na metodu, ktera vraci instanci implementujici dane rozhrani
  private readonly Dictionary<Type, Func<OurContainer, object>> _TypeCreators = new Dictionary<Type, Func<OurContainer, object>>();

  // registace typu
  public void Register(Type type, Func<OurContainer, object> creator)
  {
    _TypeCreators[type] = creator;
  }

  // vraceni instance
  public object GetInstance(Type type)
  {
     return _TypeCreators[type](this);
  }

  // genericke varianty predchozich
  public void Register<T>(Func<OurContainer, object> creator)
  {
    Register(typeof(T), creator);
  }

  public T GetInstance<T>()
  {
    return (T)GetInstance(typeof(T));
  }  

}

Jádrem našeho řešení je to, že pro každý typ (interface) máme přiřazeného delegáta, který umí vytvořit instanci třídy implementující dané rozhraní.
Tento náš kontejner můžeme nakonfigurovat tímto způsobem:

var container = new OurContainer();
container.Register<IEngine>(c => new Engine());
container.Register<ICar>(c => new Car(c.GetInstance<IEngine>()));

Zajímavý je poslední řádek – konstruktor třídy Car vyžaduje jeden parametr typu IEngine, takže při volání musíme nějak získat instanci třídy implementující toho rozhraní. A není nic krásnějšího než k této úloze použít “rekurzivně” IoC kontejner.

Nyní tedy máme k dispozici IoC kontejner, který sice neumí DI, automatické vytváření instancí (dodáváme delegáta, který se o to postará), ani některé další vymoženosti (např. řízení životnosti objektů), ale přesto může být užitečný (už jen proto, že to není žádný zbytečně přebujelý moloch).
Pojďme dále implementovat automatické vytváření instancí, včetně constructor injection:

public void Register<T, TImplementation>()
{
  // ziskame konstruktory implementujici tridy
  var ctors = typeof(TImplementation).GetConstructors();
  if (ctors == null || ctors.Length == 0)
  {
    throw new InvalidOperationException(string.Format(
	  "Appropriate constructor not found in type '{0}'.",
	  typeof(TImplementation).FullName));
  }
  var ctor = ctors[0]; // vezmeme prvni konstruktor

  // zkonstruujeme lambda expression, ktera vytvori instanci implementacni tridy
  // lambda ma jeden vstupni parametr typu OutContainer
  var containerParameter = Expression.Parameter(typeof(OurContainer), "container");
  var creator = Expression.Lambda(typeof(Func<OurContainer, object>),
    Expression.New(ctor,
      ctor.GetParameters()
	  // pro kazdy parametr konstruktoru vygenerujeme volani GetInstance na kontejneru
	  .Select(p => (Expression)Expression.Call(containerParameter, "GetInstance", new[] { p.ParameterType }))),
      containerParameter);

  // zaregistrujeme zkompilovanou lambdu
  Register<T>((Func<OurContainer, object>)creator.Compile());
}

Kód funguje tak, že si při registraci sestavíme lambda expression, kterou následně zkompilujeme a použijeme jako delegáta, který umí vytvořit třídu implementující dané rozhraní. Nic složitého.
Konfigurace je nyní o poznáni pěknější:

var container = new OurContainer();
container.Register<IEngine, Engine>();
container.Register<ICar, Car>();

Tento náš IoC/DI můžeme dále vylepšovat. Např. podpora pro instance žijící během jednoho HTTP požadavku lze jednoduše implementovat pomocí kolekce System.Web.HttpContext.Current.Items.
Dalším logickým krokem by mohlo být upravení našeho kontejneru tak, abychom ho mohli použít pomocí CommonServiceLocatoru – v tomto případě stačí odvodit naši třídu od abstraktní ServiceLocatorImplBase a implementovat dvě metody – DoGetInstance a DoGetAllInstances. To už ale jistě zvládnete sami

Úvod

Co je JavaScript?
JavaSript je jedním z dialektů standardizovaného jazyka ECMAScript. Další používané dialekty jsou ActionScript (bohatší syntaxe), JScript, InScript nebo QtScript. Ukázky v tomto článku jsou většinou otestovány v JavaScriptu verze 1.8, konkrétně implementaci SpiderMonkey, což je vůbec první implementace JavaScriptu a využívá ji např. Firefox (i když dnes v optimalizované verzi TraceMonkey). Ke SpiderMonkey je také vynikají dokumentace, kterou doporučuji strčit do záložek, pokud to myslíte s JavaScriptem vážně.
K dalšímu studiu jazyka doporučil přímo ECMAScript specifikaci, která je dostupná taky v praktické HTML verzi.
Článek popisuje i některé techniky, které se nehodí pro použití na webu, protože je ne všechny současné prohlížeče podporují. Před začátkem vývoje konzultujte minimální verze podporovaných prohlížečů s těmito pěknými tabulkami.

JavaScript je dynamický jazyk. Dynamičnost spočívá v tom, že nic nemá pevný typ (jde o slabě typovaný jazyk), objekty mohou během běhu programu měnit svoje atributy a je zde magická funkce eval, která spustí string.
JavaScript je funkcionální jazyk. Funkce lze do sebe libovolně vnořovat, přičemž vnější funkce tvoří uzávěr (closure) vnitřních funkcí.
JavaScript je objektově orientovaný, avšak beztřídní, jazyk – nemá třídy, jen objekty. Pro dědění se používají tzv. prototypy (JavaScript podporuje prototypovou dědičnost).
JavaScript neumožňuje explicitní uvolnění paměti – o řízení paměti se stará Garbagge Collector.

Datové typy (tak, jak je lze získat pomocí operátoru typeof):

• number – číslo celé (117, 015 (oktalově), 0×15 (hexa)) i desetinné (3.14, 3.14E-15)
• string – textový řetězec, “bla” nebo ‘bla’
• boolean – true nebo false
• undefined – má jedinou hodnotu undefined
• Function – funkce
• object – objekt

Kromě funkcí a objektů jsou to všechno primitivní typy, ale umí se zaboxovat.
Při porovnání hodnot máme dvě možnosti:

• Buď můžeme použít klasické != a ==, které v případě neshodnosti typů provede potřebné konverze. Takže např. 3 == “3″ je true.
• Druhou možností je použití striktního porovnání !== a ===, které neprovádí žádné konverze, takže 3 === “3″ je false.

Identifikátory v JavaScriptu jsou case sensitive (narozdíl třeba od ActionScriptu verze 1.0).

Funkce

Definice funkce může vypadat nějak takto:

function secti(a, b) {
    var c = a + b; // lokalni promenna
    a += c;
    return a + b + c;
}

Jedná se o slabě typovaný dynamický jazyk, takže typy parametrů ani návratové hodnoty se neuváději, vše se vyhodnocuje až za běhu. Pokud např. a a b budou stringy, bude se funkce chovat jinak než kdybychom použili čísla.
Při volání funkce můžeme zadat libovolný počet parametrů. Pokud nějaký definovaný parametr při volání neuvedeme, bude jeho hodnota undefined. Pokud jich bude více, můžeme se k nim dostat přes pole arguments, které obsahuje všechny předané parametry (má položku length a indexuje se klasicky od nuly hranatými závorkami). Všechny parametry se vždy předávají hodnotou, není zde žádná přímá podpora pro předání parametru odkazem.
Možnost neuvedení parametrů de facto znamená, že všechny parametry jsou volitelné. Když parametrům chceme přiřadit nějakou defaultní hodnotu, dělá se to často takto:

function secti(a, b) {
    a = a || 0; // pokud je a undefined, null nebo prazdny retezec, priradi se do nej nula
    b = b || 0;
    var c = a + b; // lokalni promenna
    a += c;
    return a + b + c;
}

Uvnitř funkce můžeme definovat lokální proměnné pomocí klíčového slůvka var, jak bylo ukázáno.

Výše ukázaný způsob zavedení funkce se nazývá function declaration (nebo také function statement) a můžeme ho poznat tak, že mezi function a otvírací závorkou je povinné jméno. Tento způsob zavedení funkce vytvoří funkci daného jména a automaticky ji přiřadí do proměnné stejného jména.
Jiným způsobem zavedení funkce je tzv. function expression (také function operator), který se pozná podle toho, že jméno funkce je v tomto případě nepovinné a zavedení funkce je součástí výrazu. To typicky znamená, že výsledek function expression přiřadíme do nějaké námi definované proměnné.

var secti = function(a, b) {
    return a + b;
};

Nyní vytváříme anonymní funkci, kterou přiřazujeme do proměnné secti. Jméno funkce můžeme uvést i v tomto případě, ale na toto jméno se můžeme odkazovat jen z těla této funkce – odnikud jinud není vidět (hodí se tak např. pro rekurzi).

var secti = function secti_blabla(a, b) { // jmeno funkce a promenne se nemusi shodovat
    return a + b; // jen tady je secti_blabla videt
};

Zjednodušeně řečeno můžeme říci, že function statement vytvoří funkci a automaticky i proměnnou stejného jména, naproti tomu function expression pouze vytvoří funkci a o uložení do nějaké proměnné se musíme postarat sami.

Každá funkce je zároveň objektem (konkrétně instancí třídy Function) a lze ji zavést (poslední, třetí, způsob) i takto: new Function(”a”, “b”, “return a + b;”)
Poslední parametr je string nesoucí tělo funkce, všechny předchozí parametry jsou názvy parametrů funkce.

Uzávěry

Funkce lze do sebe libovolně vnořovat (tj. v těle funkce můžeme definovat další funkci). Důležité je vědět, že uzávěr tvoří vždy celá funkce, ne blok příkazů uzavřený ve složených závorkách, jak je to běžné např. v C#. Tam bychom napsali kód v následujícím smyslu a vše by fungovalo.

for (var i = 0; i < poleObjektu.length; i++) {
  var item = poleObjektu[i];
  document.getElementById(item.id).onclick = function() {
    alert(item.name);
  }
}

V JavaScriptu toto ale fungovat nebude, protože uzávěr se tvoří vždy jen na úrovni celé funkce, takže to, že item definujeme uvnitř těla cyklu, nám nepomůže (v C# ano).
Od verze JavaScriptu 1.7 má náš problém snadné řešení - místo klíčového slova var použijeme nové klíčové slovo let, které vytváří uzávěr na nižší úrovni než funkce.
Pokud jsme odkázáni pracovat s nižší verzí JavaScriptu, nezbývá nám než zajistit vytvoření další úrovně uzávěru - voláním další funkce v těle cyklu:

function makeAlertFunction(message) {
    return function() { alert(message); } // vracime funkci s uzaverem na funkci makeAlertFunction
}
for (var i = 0; i < poleObjektu.length; i++) {
    var item = poleObjektu[i];
    document.getElementById(item.id).onclick = makeAlertFunction(item.name);
}

Objekty

Objekt je vlastně jen hash table, nese tedy dvojice klíč - hodnota. Hodnotou může být cokoliv, tedy i funkce. Položka se definuje prostým přiřazením: obj.novaPolozka = 5;. Pokud položka neexistuje, dostáváme při jejím čtení hodnotu undefined. K položkám se dá přistupovat dvěma způsoby:

obj.polozka = 5;
obj["polozka"] = 5;

Položku objektu lze i zrušit: delete obj.polozka;

Nyní bych rád udělal menší vsuvku a zmínil jak vypadá běhové prostředí (kontext, ve kterém náš program běží). Je to děsivě jednoduché - vše je objekt (i primitivní objekty se umí zaboxovat) a vždy se nacházíme v kontextu nějakého objektu (k němuž máme přístup pomocí všudypřítomného readonly this). Pokud jsme na top-level úrovni, ukazuje this na globální objekt (v prohlížečích je to window). Celý program v JavaScriptu je pak vlastně tělo globální funkce.

Zpět k objektům. Jak vytvořit nový objekt?

• Anonymní objekt snadno - do složených závorek uzavřeme dvojice jmeno : hodnota a oddělíme je čárkami. Hodnota může být cokoliv, klidně další objekt nebo funkce (už víme, že funkce je objekt, konkrétně instance třídy Function):

  var car = {
      name : "Honda",
      model : "Civic",
      owner : { name : "Jiri", surname : "Novak" },
      printMe : function() {
          return this.name + ' ' + this.model + ' owned by ' + this.owner.name + ' ' + this.owner.surname;
      }
  };

  Samozřejme můžeme vytvořit i prázdný objekt: var empty = {};
  Takovému způsobu zápisu objektu do složených závorek se říká object literal nebo object initializer a zápis je podobný jako v případě Jsonu. Ale rozdíly tam jsou, např. v Jsonu nemůžeme logicky použít funkce, protože slouží pouze k přenosu dat, v Jsonu jsou u stringů povoleny jen dvojité uvozovky atp...
  Pokud voláme funkci objektu (tedy metodu) car.printMe();, je před voláním metody do this přiřazeno car. Proto se metoda chová dle očekávání.

• Voláním funkce prefixované klíčovým slovem new - takové funkce je slušné pojmenovat s prvním písmenem velkým a říkat jim konstrukční funkce (constructor functions). Klíčovým slovem new řekneme, že chce vytvořit nový (prázdný) objekt a tento použít jako this uvnitř volání (konstrukční) funkce. Uvnitř funkce máme tedy k dispozici this, což je úplně prázdný objekt. Logickým cílem konstrukční funkce je tento objekt zinicializovat.

  function Car(carName, model) {
      this.name = carName;
      this.model = model;
      this.printMe = function() { // tohle neni nejefektivnejsi, stay tuned
          return this.name + ' ' + this.model;
      };
  }

  Na konstrukční funkce tudíž můžeme pohlížet podobně jako na třídy v jiných jazycích - je to totiž předpis, jak zkonstruovat konkrétní objekt. Pokud budu v dále textu mluvit o třídách, budu mluvit právě o konstrukčních funkcích.

  Pokud zavoláme toto, vytvoří se nám objekt podle očekávání: var c = new Car("Honda", "Civic");. Co když ale na slovíčko new zapomeneme? Pak nedojde k vytvoření nového prázdného objektu a jeho přiřazení do this. Bez new se jedná o úplně normální volání funkce a tudíž uvnitř funkce dojde k přiřazením do aktuálního this objektu. Pokud se nám podaří takovou funkci zavolat bez new z top-level úrovně, nadefinujeme položky name a model a funkci printMe na globálním objektu.

Následuje komentovaný příklad, na kterém si ukážeme i něco nového, zajímavého a užitečného, takže nepřeskakovat

// vytvorime promennou Car, do ktere priradime funkci se tremi parametry
// velke pismenko na zacatku jmena funkce indikuje, ze se jedna o konstrukcni funkci a tudiz by mela byt volana pomoci new
var Car = function(name, model, manufactured) {
    // nadefinujeme dve polozky v aktualnim this objektu
    this.name = name || 'Honda'; // pokud nebylo jmeno specifikovano, pouzije se 'Honda'
    this.model = model || 'Civic';

    // jsme ve funkci, takze muzeme nadeklarovat lokalni promennou
    // ta bude zcela podle ocekavani viditelna jen z teto funkce a funkci vnorenych
    // o lokalnich promennych v konstrukcnich funkcich se casto mluvi jako o privatnich polozkach objektu
    // k takovym polozkam se pristupuje jen pres jejich jmeno, tedy "made", zadne "this.made"!
    var made = manufactured;

    // nadefinujeme polozku, do niz priradime funkci, tedy vytvorime metodu objektu this
    // uvnitr metody muzeme pouzit lokalni promennou made
    this.howOld = function(now) { return now - made; }

    // stejne tak ale vidime i parametry funkce
    // parametry funkce jsou taktez oznacovany za privatni polozky objektu
    // a ze jsme pouzili stejne jmeno metody jako predtim? neva, stara se prepise
    this.howOld = function(now) { return now - manufactured; }

    // dve vyse uvedene metody pristupovaly k privatnim polozkam
    // takove metody se nazyvaji privilegovane

    // lokalni promenna muze byt jakehokoliv typu, tedy klidne funkce
    // takze toto je privatni metoda
    // k privatnim polozkam pristupujeme primo jejich jmenem
    // neprivatni polozky objektu musime prefixovat "this."
    // polozky jsou vsechno, i funkce, takze volani metody musi byt vzdy necim prefixovano
    // (v pripade tehoz objektu prefixem "this.")
    var printInfo = function () { println(this.name + " from " + made); }

    // vyse uvedene se da zapsat zkracene takto (drobne rozdily v implementaci tam ale jsou)
    function printInfo2() { println(this.name + " from " + made); }

    // je dobrym zvykem u novych trid definovat metodu toString, ktera vraci popis objektu
    // toto je public metoda, neni privatni ani privilegovana
    // vsimneme si, ze do polozky toString neprirazuji nejakou anonymni funkci jako v predchozich ukazkach,
    // ale pojmenovanou funkci - to muze pomoci pri debugu pri prochazeni stacku
    this.toString = function toString () { return this.name };
}

// vytvorime Hondu Civic s neznamym datem vyroby
var hc = new Car();
hc.howOld(); // vrati Nan (takovy ciselny undefined)
hc.toString(); // vrati "Honda"
//hc.printInfo(); // skoncilo by chybou - v konstrukcni funkci nikde nevidim prirazeni do this.printInfo

Vestavěné objekty JavaScriptu

JavaScript obsahuje pár vestavěných tříd. Jednak to jsou třídy, které zjednodušeně řečeno reprezentují zaboxované hodnotové typy (Boolean, Number, String); o třídě Function už řeč byla; a dále tu máme třídy, které nám usnadní řešení některých specifických úkolů: Date, RegExp (pro jeho vytvoření je možné použít i speciální literály uzavřené do slešů, např. var re = /ab+c/; je to samé jako var re = new RegExp("ab+c");), Math (obsahuje různé užitečné matematické funkce).

Asi tou nejzajímavější třídou je ale Array, tedy pole, konkrétně "dynamické" pole. Má položku length, která vrací hodnotu nejvyššího indexu v poli + 1. Pokud přiřazujeme do objektu pole položky s celočíselnými klíči, strkají se do pole. Protože je pole ale zároveň objekt, můžeme do něj přiřazovat i položky s nečíselnými klíči, např. pole.bla = "nazdar";

var pole = []; // to same jako new Array();
var inicializovanePole = [ 1, "bla", { name: "ja" }, 8, 5.8 ];
pole[2] = "dva"; // pole.length == 3, pole[0] == undefined, pole[1] == undefined
pole["2"] = "dva"; // stejne jako predchozi
pole.push("dalsi"); // dana hodnota se umisti na konec pole
pole[pole.length] = "dalsi"; // lamerska verze predchoziho
var dalsi = pole.pop(); // vrati posledni prvek pole a prvek z pole vynda
pole.length = 1; // nastaveni velikosti pole

JavaScript obsahuje vedle vestavěných tříd také pár užitečných funkcí. To nejzajímavější je dozajisté eval, která umí spustit JavaScriptový kód uložený ve stringu.

this

Klíčové slovíčko this je v JavaScriptu obestřeno mnoha mýty, přitom jeho fungování je docela jednoduché.
Na začátku programu je nastavené na globální objekt (v případě prohlížeče objekt window) a změnit se dá čtyřmi způsoby:

• Zavoláním funkce s klíčovým slovem new. Jak už bylo řečeno, v tomto případě dojde k vytvoření nového prázdného objektu a jeho přiřazení do this, tedy něco jako this = {};. Po návratu z (konstrukční) funkce je this vráceno na původní hodnotu.
• Volání metody. Viz příklad výše - hc.howOld();. Dojde k nastavení thisu na hc, zavolání funkce howOld a obnovení původní hodnoty thisu.
• Volání metody pomocí call objektu Function. Metodu můžeme zavolat takto: hc.howOld.call(someOtherObject, par1, par2);. Zde se stane něco podobného jako v předchozím případě, pouze this je nastaveno na námi zadanou hodnotu someOtherObject. Můžeme tedy volat metodu nad objektem, který danou metodu vůbec neobsahuje.
• Obdobně jako předchozí případ funguje apply. Rozdíl je pouze v tom, že nyní nepředáváme parametry jednotlivě, ale apply má dva parametry - první parametr je nová hodnota thisu, druhý parametr je pole parametrů. Metoda apply se využívá např. tehdy, když chceme z funkce zavolat funkci se stejnými parametry jako má aktuální funkce - pak zavoláme funkce.apply(this, arguments); Jak bylo řečeno, arguments obsahuje pole aktuálních parametrů, takže tímto ho pouze přepošleme do jiné funkce.

Prototypy

Vše je objekt, tedy i funkce je objektem. To je vidět v předcházejícím odstavci - funkce (reprezentovaná objektem třídy Function) má metody call a apply. Dále má ještě metodu toString(), která vrací zdrojový kód funkce (pokud je k dispozici). Objekt Function má dále položku length, která udává počet deklarovaných parametrů, a hlavně má položku prototype. prototype obsahuje položky, které jsou společné pro všechny objekty vytvořené pomocí této (konstrukční) funkce.
V praxi to funguje takto: napíšeme třeba var spz = hc.spz;. JavaScript se nejprve podívá, zda má objekt hc nějakou položku s názvem spz. Pokud ano, prostě ji vrátí. Pokud ne, podívá se do objektu Car.prototype, zda ten nemá položku položku spz. Pokud ji ani ten nemá, vrátí se undefined. Do objektu Car.prototype se dívá proto, že hc bylo vytvořeno pomocí konstrukční funkce Car.
Důležité je si uvědomit, že prototype je pořád jen jeden, bez ohledu na to, kolik objektů jsme pomocí dané konstrukční funkce vytvořili - všechny používají ten samý prototype. prototype si tedy můžeme představit jako kontejner pro statické položky třídy.
Jak je to ale s přiřazením do takové položky? To probíhá jinak, tak bacha na to. Když uděláme hc.spz = 'neco';, tak se JavaScript koukne, jestli existuje v objektu hc položka s názvem spz. Pokud ano, tak je její hodnota přepsána novou hodnotou. Pokud položka není nalezena, je v objektu vytvořena. Při přiřazování se prototype neuplatní!

var hc = new Car();
var sf = new Car("Skoda", "Fabia");

// zajistime, aby vsechny objekty vytvorene pomoci Car mely polozku spz
Car.prototype.spz = 'prvni';
println(hc.spz); // 'prvni'
println(sf.spz); // 'prvni'

// pri prirazeni se prototype neuplatnuje
hc.spz = 'druha';
println(Car.prototype.spz); // 'prvni'
println(hc.spz); // 'druha'
println(sf.spz); // 'prvni'

// samozrejme kdyz priradime do prototype...;)
Car.prototype.spz = 'treti';
println(Car.prototype.spz); // 'treti'
println(hc.spz); // 'druha'
println(sf.spz); // 'treti'

// oba objekty byly zkonstruovany stejnou constructor function
println(hc.constructor == sf.constructor); // true
// a byla to constructor function Car
println(hc.constructor == Car); // true

// zmena prototypu bez explicitniho vypsani jmena constructor function
hc.constructor.prototype.spz = 'ctvrta'; // stejne jako Car.prototype.spz = 'ctvrta';
println(Car.prototype.spz); // 'ctvrta'
println(hc.spz); // 'druha'
println(sf.spz); // 'ctvrta'

// vyse uvedene neplati jen na stringy, ale na vse, tedy i na funkce/metody

Co je vhodné umístit do prototype? Jsou to položky, které se nemění, tzn. především metody. Když totiž umístíme metodu do prototype, tak se už při každém volání konstrukční funkce (tedy vytváření nové instance) nebude metoda znovu vytvářet a přiřazovat do this, ale místo toho bude existovat jen jednou v prototype - tudíž šetříme pamětí (viz poznámka o neefektivnosti v jednom z předchozích příkladů).
Ale pozor, do prototype můžeme dát jen ty metody, které nejsou privilegované, tedy ty, které si nesahají na nějakou lokální proměnnou nebo parametr konstrukční funkce. Ono to totiž ani nedává moc smysl.

var Car = function(name) {
    // blbost!
    this.constructor.prototype.testMethod = function() { return name; }
}

Abychom měli přístup k privátním položkám, musí být přiřazení do prototype umístěno v konstrukční funkci. To ale znamená, že vytvoření oné metody a přiřazení do prototype probíhá při každém vytvoření instance třídy Car, přičemž se do prototype přiřadí funkce, která má uzávěr posledního volání funkce Car! Tedy metoda testMethod by vždy vracela jméno poslední vytvořené instance.
Stačí zapamatovat si jednoduché pravidlo - nepřiřazovat do prototype v konstrukční funkci, ale až za ní.

Kdyby někdo ale výše popsané chování vyžadoval (což se může stát, člověk nikdy neví), tak bych zde upozornil na jednu věc (vyžaduje ale znalosti z další části článku, takže tuto poznámku zatím klidně přeskočte). Privilegované položky v prototype totiž nejsou enumerabilní, tj. pokud budeme projíždět všechny položky objektu cyklem for-in, nedostaneme se k privilegované metodě. A to může způsobit problémy při implementaci vícenásobné dědičnosti. Abychom se tomuto problému vyhli, nepřiřazujeme v ukázce do Car.prototype, ale do this.constructor.prototype, což bude např. v případě volání konstruktoru z poděděné třídy BestCar znamenat totéž co BestCar.prototype. Použitím konstrukce this.constructor.prototype tedy umožníme přiřazení do prototype aktuálního objektu a vyhneme se nutnosti vyenumerovat tuto položku při kopírování z prototype do prototype.

Kromě metod můžeme do prototypů umístit i konstanty, pokud chceme k těmto konstantám přistupovat přes instance. V opačném případě je vhodnější umístit konstanty přímo do objektu konstrukční funkce, tedy např. Car.MAX_SEATS = 10;. V takovém případě musíme ale počítat s tím, že (pokud nepoužijeme nějaký trik) se k této konstantě nedostaneme přes jméno odvozené třídy, takže např. BestCar.MAX_SEATS bude undefined.

Prototypy podrobněji

Výše uvedený popis prototypů v JavaScriptu je trošku zjednodušený, avšak pro běžnou praxi dostatečný. Pro zájemce se mrkneme na prototypy podrobněji.
Specifikace ECMAScriptu mluví o vnitřní property každého objektu s názvem [[Prototype]], ke které se nedá nijak dostat (např. SpiderMonkey to ale umožňuje přes __proto__). A právě toto je ta property, přes kterou se skutečně provádí hledání položky objektu! Je užitečné znát tyto skutečnosti:

• Prototypové fallbackování při hledání properties se neděje přes property prototype (instance ani žádnou takovou property nemá), ale přes nepřístupnou property [[Prototype]] (kterou má každý objekt).
• Každá funkce (instance "třídy" Function) má property prototype, což je iniciálně prázdný objekt s položkou constructor, která vede zpět na onu funkci. Toto je jediná "standardní" property s názvem constructor v JavaScriptu.
• Když vytvoříme instanci objektu podle nějaké konstrukční funkce (klasické new), tak se do [[Prototype]] nové instance zkopíruje property prototype použité konstrukční funkce. Nová instance nemá žádnou property jménem prototype.
• [[Prototype]] sice přímo měnit nemůžeme (protože k ní nemáme většinou žádný přístup), ale můžeme využít skutečnosti z předchozího bodu a měnit její položky přes property prototype použité konstrukční funkce, např. přiřazovat do Car.prototype.spz. Pokud to chceme dělat dynamičtěji, může použít konstrukci hc.constructor.prototype (která ale při změně prototypu za běhu nemusí fungovat podle očekávání) nebo nejlépe použít funkci getPrototypeOf, která byla zavedena v ECMAScriptu 3.1 (JavaScriptu 1.8.1).
  Pokud tyto novější verze použít nemůžeme, ale v budoucnu se to pravděpodobně změní, můžeme použít ne-ideální vlastní implementaci této funkce, jak je popsána mj. v tomto článku (sekce "Cross-Browser Implementation").
• Když vytváříme funkci, tak tím vlastně vytváříme instanci třídy Function. Z předchozích bodů tedy vyplývá, že třeba Car má jako [[Prototype]] nastavenu hodnotu Function.prototype.
• Operátor instanceof vůbec nesahá na property constructor. Místo toho vezme property prototype konstrukční funkce (zadána jako pravý operand). Dále pak vezme [[Prototype]] levého operandu a dokud není null, tak při shodě vrací true, jinak postupuje přes [[Prototype]] dále chainem (kerý končí u prapředka Object, který má [[Prototype]] nastaven na null).
• Pokud tedy přiřadíme do property prototype konstrukční funkce po vytvoření instance, tak nám instanceof nebude fungovat dle očekávání.

Properties

Jak jsme si již řekli, položky objektu (properties) lze definovat prostým přiřazením, tedy obj.polozka = hodnota; či obj["polozka"] = hodnota;. V moderních JavaScriptových enginech (implementující tuto vlastnost ECMAScriptu5) je tu ale ještě další možnost -
property můžeme definovat pomocí speciální funkce defineProperty, kterou si hned ukážeme na příkladu:

// prvni parametr je objekt, pro ktery property definujeme
// druhy parametr je jmeno property
// treti parametr je tzv. property descriptor, coz je anonymni objekt s predepsanymi properties
Object.defineProperty(Car.property, "someProperty", {
	value: 36, // hodnota
	writable: true, // zda je mozne do property priradit
	enumerable: true, // zda bude property videt pri enumerovani pomoci for cyklu
	configurable: false // zda se da property smazat pomoci delete
});

Je to tedy velmi podobné, jako kdybychom udělali Car.property.someProperty = 36;, pouze máme větší kontrolu nad vlastnostmi definované property. Takovémuto property descriptoru se říká data descriptor.
Zajímavější jsou accessor descriptory:

Object.defineProperty(Car.property, "someProperty", {
	get: function() { return this.someValue; }, // getter (volitelny)
	set: function(value) { this.someValue = value; }, // setter (volitelny)
	//writable: true, // writable nema u accessor descriptoru smysl
	enumerable: true, // zda bude property videt pri enumerovani pomoci for cyklu
	configurable: false // zda se da property smazat pomoci delete
});

Buď getter nebo setter lze vynechat a tím docílíme read-only, resp. write-only property.
Pokud chceme získat property descriptor nějaké existující property, máme k dispozici funkci getOwnPropertyDescriptor.

Jak jsem psal, výše popsané je záležitost ECMAScriptu 5 a třeba ve webových prohlížečích je v současnosti možné toto použít pouze na DOM objekty v IE8+. Pokud potřebujeme nějaké takové chování už nyní, můžeme v prohlížečích Safari, Opeře, Firefoxu a Chrome, příp. JS enginech SpiderMonkey a TraceMonkey, použít následující konstrukce:

// definice na existujicim objektu
Car.prototype.__defineGetter__("someProperty", function() { return this.propValue; } );
Car.prototype.__defineSetter__("someProperty", function(value) { this.propValue = value; } );

// definice v ramci object initializeru
var obj2 = {
    get someProperty() { return this.propValue; },
    set someProperty(value) { this.propValue = value; }
};

Místo funkce getOwnPropertyDescriptor zde můžeme použít funkce __lookupGetter__ a __lookupSetter__.
A když jsme už u těch podtržítkových záležitostí, tak přihodím jednu třešňičku, kterou umožňuje SpiderMonkey. Do obj.__noSuchMethod__ můžeme přiřadit funkci, která očekává dva parametry. První je jméno funkce a druhý její parametry. Tato přiřazená funkce bude zavolána vždy, když někdo na objektu obj zavolá metodu, která není definována.

Tato stránka docela pěkně ukazuje, kde si člověk může dovolit použít jaké způsoby vytváření properties.
K properties s gettery a/nebo settery bych ještě dodal, že jsou to de facto metody, takže pokud přistupují jen k public položkám (tj. přes this), patří do prototype.

Statements

Teď si dáme trošku oddech a mrkneme na statements. Ty jsou téměř stejné jako v C, takže je netřeba moc rozebírat - máme tu for, while, do-while, break, continue, if-else, switch...
Za zmínku snad stojí jen for-in. Ten nám totiž umožní iterovat přes všechna jména položek objektu:

for(var key in someObj) {
    println(key + ': ' + someObj[key]); // klic: hodnota
}

Pokud chceme iterovat přímo přes hodnoty položek objektu, můžeme přes for each-in:

for each (var v in someObj) {
    println(v);
}

Dědičnost

A to nejlepší nakonec - klasická třídní dědičnost není JavaScriptem přímo podporována, JavaScript umí prototypovou dědičnost (vzpomeňte na fallbackování při hledání properties popsané výše). JavaScript je ale natolik ohebný jazyk, že je možné klasickou třídní dědičnost různými způsoby simulovat. Zde bych rád ukázal některé používané přístupy a přidám i nějaké svoje nápady. Nejprve předvedu řešení, která jsou k vidění na internetu a nejsou správná, a popíšu, v čem je u nich problém - i některá špatná řešení může být důležité znát.
V následujících příkladech budu předpokládat, že T1 je bázová třída a T2 je třída odvozená od T1.

Často je k vidění následující konstrukce: T2.prototype = new T1;
Toto velmi jednoduché řešení jakž-takž funguje, ale má řadu nevýhod:

• Při této deklaraci dojde k vytvoření instance třídy T1, což nemusí být úplně ok (kdyby třeba T1 alokovala nějaké zdroje apod.).
• T2.prototype.constructor bude nelogicky roven T1. Lze řešit přiřazením T2.prototype.constructor = T2;
• T2 nezdědí z T1 privátní položky, takže volání privilegovaných metod selže.
• Při vytváření instance T2 se nevolá konstrukční funkce T1.
• V této podobě neumožňuje vícenásobnou dědičnost.

Výhodou tohoto řešení je jednoduchost zápisu.

Následující řešení je zajímavější (avšak stále ne moc dobré):

var T2 = function(cpar1, cpar2, cpar3) {
    // vytvorime public polozku s nazvem parentClass, ktera ukazuje na constructor function predka
    // tim dame do T2 metodu, ktera umi zkonstruovat objekt typu T1
    this.parentClass = T1;
    // zde udelame to, pred cim jsem varoval - zavolame constructor function bez "new"
    // protoze se ale jedna o volani metody objektu T2, preda se do ni aktualni this
    // takze tato trida bude zinicializovana jako T1
    this.parentClass(cpar1, cpar2 + cpar3);
    // nyni nasleduji T2 specific zalezitosti jako obvykle
}

Výhody:

• Informace o dědění je obsažena přímo v definici třídy.
• Můžeme volat konstruktor předka s libovolnými parametry.
• Privátní položky T1 jsou správně zinicializovány a neperou se s položkami T2, neboť každé žijí v jiné closure.
• Nejsme omezeni na jednoho předka - můžeme volat více constructor functions.

Nevýhody:

• Nedědí se prototype.
• Zápis dědičnosti jsou dva příkazy.
• Zavádí se nová public položka objektu (v ukázce pojmenovaná parentClass).

U posledních dvou nevýhod jsem sám vymyslel (heč! ) jak se jich zbavit. Jednoduše využijeme jedné z možností, jak protlačit vlastní this do funkce.

var T2 = function(cpar1, cpar2, cpar3) {
    // zavolame constructor function T1, ale podstrcime mu aktualni this
    T1.call(this, cpar1, cpar2 + cpar3);
    // pokud maji T1 a T2 stejne parametry, lze zapis zkratit nasledovne
    //T1.apply(this, arguments);
    // nyni nasleduji T2 specific zalezitosti jako obvykle
}

Toto řešení nám krásně pořeší dědění instančních položek, ale stále nám zde zůstává problém s neděděním prototypu. Zde ukážu několik přístupů k dědění prototypu, resp. vytvoření správného prototype chainu - prostě aby se při hledání property v prototypech správně propadávalo do prototypů nadtříd.

• Zdánlivým cílem je, aby T2.prototype obsahovalo to samé, co T1.prototype, plus něco navíc. Řešení je tudíž naprosto přímočaré:

  T2.prototype = T1.prototype;
  // obnoveni konstruktoru
  T2.prototype.constructor = T2;
  // T2 specific prototype polozky

  Nevýhodou tohoto přístupu je to, že neumožňuje vícenásobnou dědičnost. Té se ale v praxi já osobně snažím vyhnout, protože to přináší další zlo, na které je třeba pamatovat - možné překrývání jmen položek jednotlivých bázových tříd.
  Další (poměrně zásadní) nevýhodou tohoto řešení je to, že když něco přidáme do T2.prototype, tak se nám to objeví i v T1.prototype.

• Pokud chceme přesto umožnit vícenásobnou dědičnost, postupoval bych následovně. Do všech funkcí si přidáme metodu extend, která nám překopíruje všechny (resp. všechny enumerabilní) položky daného prototypu do prototypu aktuálního objektu.

  // metoda na kopirovani z prototypu do prototypu
  // pokud nechceme vicenasobnou dedicnost, tak ji nepotrebujeme
  Function.prototype.extend = function extend(b) {
      b = b.prototype;
      for (var i in b) {
  	    // SpiderMonkey/TraceMonkey specific
          var g = b.__lookupGetter__(i), s = b.__lookupSetter__(i);
          if (g || s) {
              if (g) this.prototype.__defineGetter__(i, g);
              if (s) this.prototype.__defineSetter__(i, s);
          } else {
              this.prototype[i] = b[i];
          }
      }
  };

  Místo přiřazení do prototypu pak stačí zavolat T2.extend(T1);.
  Nevýhodou tohoto řešení je, že pokud přidáme něco dodatečně do T1.prototype, tak se nám změna neprojeví v T2.prototype. Pokud máme striktně oddělenu "implementaci" a "použití", tak to není problém, ale trošku se tím omezujeme v jinak krásně dynamickém prostředí JavaScriptu.
  Na internetu je občas toto řešení s kopírováním properties použito i na implementaci jednoduché dědičnosti - to je ale zbytečné a je lepší použít některé řešení popsané níže.

• Abychom využili prototypovou dědičnost pro implementaci třídní dědičnosti naplno, potřebujeme dosáhnout toho, aby při nenalezení property v T2.prototype došlo k hledání v T1.prototype (potřebujeme zřetězit prototypy). Takže cílem je, aby skrytá property [[Prototype]] objektu T2.prototype (tedy "T2.prototype.[[Prototype]]") byla rovna T1.prototype.

  // metoda na zretezeni prototypu
  Function.prototype.extend = function extend(child) {
      // pokud mame primy pristup k [[Property]] pres __proto__ (SpiderMonkey/TraceMonkey), je to jednoduche
      if (child.prototype.__proto__) {
          child.prototype.__proto__ = this.prototype;
      } else {
          // vytvorime si pomocnou konstrukcni funkci...
          var F = function() { };
          // ...ktera ma prototype nastaveno na "T1.prototype"
          F.prototype = this.prototype;
          // "T2.prototype.[[Prototype]]" bude odkazovat na F.prototype (=== T1.prototype)
          child.prototype = new F();
          // nastavime spravny constructor
          child.prototype.constructor = child;
      }
  };
  
  T1.extend(T2); // pouziti
  

  Když můžeme [[Prototype]] přímo změnit, je implementace jednoduchoučká. Pokud ne, musíme si trošku pomoci.
  Abychom zajistili, že "T2.prototype.[[Prototype]]" bude nastaveno na T1.prototype, musíme T2.prototype vytvořit nějakou funkcí, která má prototype rovno T1.prototype. A není nic jednoduššího, než si takovou pomocnou funkci vyrobit (F).

• Výše uvedené řešení je nejlepší, jaké v době psaní článku znám. Protože se ale může tato "best-practice" změnit, může být do budoucna výhodné abstrahovat způsob vytváření tříd, resp. hierarchie tříd, jak to ukazuje např. článek Daniela Steigerwalda.

Finální komentovaná ukázka dědičnosti

var Trida1 = function(cpar1, cpar2) {
    // instancni polozky
    this.field1 = cpar1 + cpar2;
    this.field2 = "hola";
    // privatni polozky
    var pfield1 = cpar2;
    var pfield2 = "hola hej";
    // privatni metoda
    var pmethod1 = function(par1) { println("Trida1.pmethod1 called"); };
    // metoda pristupujici k privatnim polozkam, tedy privilegovana
    this.method1 = function(par1) { println("Trida1.method1 called"); this.method2(); println(pfield1); };
    // property pristupujici k privatnim polozkam (SpiderMonkey/TraceMonkey specific syntax)
    this.__defineGetter__("prop1", function() { return pfield1; } );
    println("Trida1 contructor called");
};

// metoda (a prip. property) pracujici pouze nad public polozkami
Trida1.prototype.method2 = function(par1) { println("Trida1.method2 called"); };
// konstanty dostupne pres instance
Trida1.prototype.CONST1 = 1;
// konstanty dostupne pres jmeno tridy
Trida1.CONST2 = 2;

// podedime tridu
var Trida2 = function(cpar1, cpar2, cpar3) {
    // volame konstruktor predka se dvema parametry
    Trida1.call(this, cpar1, cpar2 + cpar3);
    // instancni polozka
    this.newfield1 = cpar1;
    // privatni polozka stejneho jmena jako privatni polozka v predkovi
    // diky ruznym closures zadny problem
    var pfield1 = cpar2;
    // property, ktera nam zpristupnuje privatni polozky pfield1 teto tridy (SpiderMonkey/TraceMonkey specific syntax)
    this.__defineGetter__("prop2", function() { return pfield1; } );
    println("Trida2 contructor called");
};

Trida1.extend(Trida2); // zretezime prototypy

// tridy nadefinovany, nyni je jdeme pouzivat
var t1  = new Trida1(58, 12);
var t2  = new Trida2(-28, -98, -5);
var t22 = new Trida2(59, 65, 158);
t1.method1();
t2.method1();
// cteni privatnich polozek stejneho jmena
println(t22.prop1);
println(t22.prop2);

Singleton

Jako bonus na závěr bych ukázal dvě možnosti, jak implementovat návrhový vzor singleton, který se často v JavaScriptu označuje jako module pattern.

// nadeklarujeme funkci, kterou hned zavolame
var Singleton1 = function() {
    // datove polozky musi byt jako lokalni promenne
    // prirazeni do this by znamenalo prirazeni do aktualniho objektu, coz muze byt ledasco
    var val1 = 1;
    var val2 = 2;
    var val3 = 3;

    // z funkce vracime anonymni objekt, ktery tvori verejny interface pro nas singleton
    return {
        prop1 : 2,
        funkce : function(par1, par2) {
            return par1 + par2;
        },
        get value1() { return val1; }, // SpiderMonkey/TraceMonkey specific syntax
    }
}(); // vsimnete si () - funkci ihned volame

Udělali jsme to, že jsme nadeklarovali funkci, ale nijak jsme ji nepojmenovali ani do ničeho nepřiřadili, ale hned po definici jsme ji zavolali. Funkce vrací anonymní objekt, který tvoří veřejný interface pro náš singleton a pouze přes něj můžeme přistupovat k privátním položkám singletonu. Ty jsou implementovány jako lokální proměnné oné nepojmenované funkce.

// nadeklarujeme konstrukcni funkci, kterou hned zavolame pomoci new
var Singleton2 = new function() {
    // datove polozky mohou byt privatni i public
    this.val1 = 1;
    var val2 = 2;
    var val3 = 3;

    this.prop1 = 2;
    this.funkce = function(par1, par2) {
        return par1 + par2;
    }
    this.__defineGetter__("value1", function() { return val1; });
};

Toto řešení funguje tak, že nadeklarujeme konstrukční funkci a hned ji zavoláme pomocí new. Zde je úroveň "zatajení implementace" o něco nižší, neboť pomocí Singleton2.constructor se dostaneme k oné nepojmenované konstrukční funkci.
Rozdíl mezi těmito dvěma řešeními je spíše kosmetický a není problém vymyslet další způsoby implementace singletonu.

Shrnutí

• JavaScript je dynamický objektově orientovaný skriptovací jazyk s prototypovou dědičností
• všechno je objekt, včetně funkcí
• objekt je hash mapa (jméno -> hodnota)
• objekt můžeme vytvořit dvěma způsoby - zavoláním new Trida nebo pomocí object literalu: { name: "Ja", age : 27, } (podobné jako Json)
• nějaký objekt je vždy aktuální - this (na top-level úrovni je to globální objekt, v prohlížečích window)
• aktuální objekt (this) můžeme změnit čtyřmi způsoby - zavoláním funkce na objektu (tedy metody), voláním new Trida a dále pomocí speciálních metod třídy Function: call a apply
• Každá funkce má přiřazen prototype, na který vede odkaz (přes "skrytou" property [[Prototype]]) ze všech objektů, které byly vytvořeny touto (konstrukční) funkcí.
• prototype se používá především na definování metod
• co bylo definované jako poslední (stejného jména), to platí
• tento článek nepostihuje všechny možnosti JavaScriptu, ty jsou daleko širší
• design mého blogu není moc přívětivý na dlouhé výpisy kódů, proto si můžete článek prohlédnout také v plain html nebo stáhnout jako PDF

© Michal Augustýn (Augi) 2009 - 2010

ASP.NET MVC Futures

Začněme s Futures. Assembly je ve své poslední verzi poměrně hubená, dost možná proto, že většina věcí byla přesunuta přímo do core assembly. Tradičně zde nalézáme MVC Controls, tedy kontrolky pro ASP.NET WebForms s prefixem mvc:. Idea to je zajímavá, protože aspx šablony jsou s těmito kontrolkami takové více konzistentní, než když máme kód “rozbitý” voláním Html helperů apod. Prostě a jednoduše, aspx by mělo obsahovat ideálně žádný “imperativní kód” (ideálně jen “deklarativní”) a MVC Controls k tomuto cíli vedou. Zůstává jen otázka, proč se za tak dlouhou dobu kontrolky nedostaly do core assembly a ani se nestaly příliš oblíbenými…
Další věci, které najdeme ve Futures, jsou povětšinou jen drobnosti, které sice potěší, ale nepřináší nic převratného.

MVCContrib

Když už zmiňuji Futures, určitě bych se měl zmínit také o MVCContrib – to je komunitní rozšíření pro ASP.NET MVC. Najdeme zde další užitečné maličkosti, ale i jednu poměrně zajímavou věc – T4MVC, která nám umožní generovat odkazy v silně typovém stylu. Ale na můj vkus je použitý způsob zajištění silné typovosti při generování odkazů příliš invazivní a očekávám, že se zapracuje na zvýšení výkonnosti generování odkazů pomocí generik. V současné době je ale T4MVC velmi dobrá (a hlavně výkonná) alternativa.

ASP.NET MVC 3

A teď k oné zmiňované roadmapě. Opět zde najdeme nějaké blbinky, jako např. možnost jedním ajaxovým voláním zupdatovat více DIVů na stránce, a lepší podpora klientského programování vůbec – třeba užší návaznost na jQuery (UI) nebo podpora pro client-side templates, které nám umožní formátovat příchozí json data. Vůbec to vypadá, že propojení server-side a client-side kódu je zajímavý úkol, který by se měl ještě nějak pěkně vyřešit.
Dále se píše o “dependency injection at all levels”, tedy možnosti jednoduše a unifikovaným způsobem nahradit/doplnit nějakou funkcionalitu v ASP.NET MVC. S tím trošku souvisí i užší integrace s MEF.
To nejzajímavější se ale skrývá pod položkou “View Engine Options“, kde se píše o experimentech s “new streamlined view engine syntax” – měl jsem možnost ho vidět a vypadá opradu skvěle. Dále se tu píše o snadnější integraci ostatních view-enginů, což také potěší. Osobně budu rád, když se zbavím defaultního aspx view-enginu.

Shrnutí

Mně osobně na ASP.NET MVC vadil právě defaultní aspx view-engine, takže jsem rád, že se ledy v této oblasti pohnuly – ať už to je nový view-engine nebo lepší podpora pro alternativní view-enginy. Také lepší podpora pro client-side programování a lepší extensibilita pomocí IoC kontejnerů a MEF jistě potěší.
Co byste rádi viděli v dalších verzích ASP.NET MVC Vy?

(Render)Action

Pokud jste chtěli v ASP.NET MVC 1 znovupoužít nějaký kód ve view, pravděpodobně jste vytvořili ascx soubor (partial view) a pak ho renderovali pomocí metody Html.RenderPartial. Užitečné, ale není to vhodné, pokud potřebujeme nějakou více autonomní partial view – typicky, aby partial view sosal nějaká data z Modelu. Jinými slovy, pokud nemůžeme nebo nechceme předávat data z rodičovského view do partial view a partial view si data tedy musí načíst sám.
Protože přistupovat k Modelu přímo z View je prasečina, máme tu k dispozici náhradu – metody Html.RenderAction a Html.Action. První metoda slouží k tomu, že nám vyrenderuje danou akci. Tzn. specifikujeme controller a action a ASP.NET MVC se postará o to, že se tato akce zavolá a dojde tedy k renderu. Druhá metoda, Html.Action, udělá to samé, ale výsledek volání akční metody nevyrenderuje, vrátí nám ho jako string.
Akční metody, které voláme takto přes Html.(Render)Action, se nazývají child action methods a pokud chceme zajistit, aby určitá akční metoda byla volatelná pouze takto (a ne jako klasická akční metoda), můžeme ji označit atributem ChildActionOnly.

Silně typový HtmlHelper

Pokud jsme chtěli v čistém ASP.NET MVC 1 vykreslit třeba inputítko pro nějakou property modelu (resp. view-modelu), museli jsme udělat něco jako Html.TextBox(”Price”), tedy použít stringovou konstantu. Nyní je HtmlHelper silně typový, genericky zná typ (view)modelu, což nám umožňuje nyní zapsat pěknější Html.TextBoxFor(m => m.Price).

ModelMetadata

Třída ViewDataDictionary nyní neobsahuje pouze property Model, ale také nově ModelMetadata (stejnojmené třídy), která nese informace o viewmodelu. Tato data se načítají pomocí zvoleného ModelMetadataProvideru, defaultně je to DataAnnotationsModelMetadataProvider, který používá atributy z jmeného prostoru System.DataAnnotations. Pomocí ViewModel.ModelMetadata se tedy můžeme dostat k dašlím zajímavým informacím o viewmodelu, což umožnilo vylepšení validací, a to jak server-side, tak client-side (v JavaScriptu). Např. není problém udělat ani remote client-side validace.

Templating

Asi nejzásadnější věc, které vznikla díky ModelMetadata, je templating. Templating je zjednodušeně řečeno mechanismus, který nám umožní pro každý datový typ specifikovat, jak se bude renderovat pro prohlížení (DisplayTemplate) a pro editaci (EditorTemplate). K tomu slouží především metody Html.DisplayFor a Html.EditorFor.
Pokud chceme např. vytvořit templates pro třídu Product, stačí vytvořit ascx soubory (de facto klasické partial views) v podadresářích DisplayTemplates a EditorTemplates.
Velice pěkný a podrobný seriál o templatingu v ASP.NET MVC 2 napsal Brad Wilson, zájemcům o hlubší poznání doporučuji.

Ostatní

V ASP.NET MVC 2 přišlo i několik drobných změn, které mohou zpříjemnit život, např. asynchronní controller, který může přispět k větší výkonnosti naší aplikace, explicitnější zápis volitelných routovacích parametrů pomocí UrlParameter.Optional (podrobnější popis od Phila Haacka), nebo explicitní zápis defaultních hodnot parametrů akčních metod pomocí standardního atributu DefaultValue.

Bonus: generování odkazů

Jak jistě víte, odkazy se ve view generují často pomocí Html.ActionLink. Defaulně se mu ale předávají stringy, což jak víme, je fůj. Takže v MvcFutures byly k dispozici metody, které umějí generovat odkazy silně typově, pomocí generik a lambda funkcí. Velmi pěkné! Ale strašlivě pomalé
Právě proto vznikl projekt T4MVC (nyní součást projektu MvcContrib), který využívá T4 (generování kódu ještě před kompilací) a umožňuje bezpečné generování odkazů. Osobně ale doufám, že se podaří urychlit původní generování pomocí generik a budu jej moct v pohodě používat. Proč? Jednoduše proto, že se mi takový zápis líbí víc

Předpokládejme teď ale situaci, kdy web má pro více jazyků stejnou strukturu, liší se jen obsah a url. Pak jistě nebudeme chtít mít controllery s názvy Product, Produkt, Producto atd. a podobně pro akční metody. Tedy vnitřek aplikace bude pro všechny jazyky stejný, lišit se budou pouze url (lokalizaci obsahu teď řešit nebudeme). A abychom nemuseli mít uvnitř aplikace code-path pro každý jazyk, bylo by pro nás nejvýhodnější převést problém na předchozí případ, tedy pracovat jen s jedněmi názvy. Naším cílem je tedy jakási normalizace url do standardního tvaru.

Ve webové aplikaci většinou pracujeme s url na dvou místech – hned na začátku zpracování požadavku (abychom věděli, co vůbec dělat, jaký controller a akční metodu vybrat) a při generování url. Obě tyto věci má pod palcem routing, takže si napíšeme vlastní routovací pravidlo, což je velmi jednoduché. Odvodíme třídu od standardní System.Routing.Route a přetížíme metody GetRouteData (používá se na začátku zpracování požadavku) a GetVirtualPath (používá se při generování url), ve kterých zajistíme nahrazení lokalizovaného stringu za normalizovaný, resp. opačně. Jde nám tedy o to, abychom po vstupu url do systému ji znormalizovali, a po výstupu ze systému ji zlokalizovali.
Zde uvedu příklad, který umožní odekorovat controller atributem ControllerName a tím změnit název controlleru pro routing (tedy obdoba již zmiňovaného ActionName).

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Interface)]
public class ControllerNameAttribute : Attribute
{
    public ControllerNameAttribute(string nameForRouting)
    {
        NameForRouting = nameForRouting;
    }
 
    public string NameForRouting
    {
        get;
        set;
    }
}
 
public class LocalizableRoute : Route
{
 
    public LocalizableRoute(string url, IRouteHandler routeHandler)
        : base(url, routeHandler)
    {
    }
 
    public override RouteData GetRouteData(System.Web.HttpContextBase httpContext)
    {
        var res = base.GetRouteData(httpContext);
        if (res == null)
        {
            return null;
        }
        object o;
        string s;
        if (res.Values.TryGetValue("controller", out o) && (s = o as string) != null)
        {
            if (RouteToController.TryGetValue(s, out s))
            {
                res.Values["controller"] = s;
            }
        }
        return res;
    }
 
    public override VirtualPathData GetVirtualPath(RequestContext requestContext, RouteValueDictionary values)
    {
        object o;
        string s;
        if (values.TryGetValue("controller", out o) && (s = o as string) != null)
        {
            if (ControllerToRoute.TryGetValue(s, out s))
            {
                values["controller"] = s;
            }
        }
        return base.GetVirtualPath(requestContext, values);
    }
 
    static Dictionary<string, string> RouteToController = new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase);
    static Dictionary<string, string> ControllerToRoute = new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase);
 
    static LocalizableRoute()
    {
        var ct = typeof(System.Web.Mvc.IController);
        var at = typeof(ControllerNameAttribute);
        foreach (var a in AppDomain.CurrentDomain.GetAssemblies().Where(aa => !aa.GlobalAssemblyCache))
        {
            foreach (var t in a.GetTypes().Where(tt => tt.IsClass && !tt.IsAbstract && ct.IsAssignableFrom(tt)))
            {
                var controllerName = t.Name;
                if (controllerName.StartsWith("T4MVC_"))
                {
                    continue;
                }
                var att = t.GetCustomAttributes(at, true);
                if (att != null && att.Length > 0)
                {
                    var routingName = ((MvcUtils.Attributes.ControllerNameAttribute)att[0]).NameForRouting;
                    if (controllerName.EndsWith("Controller"))
                    {
                        controllerName = controllerName.Substring(0, controllerName.Length - "Controller".Length);
                    }
                    if (RouteToController.ContainsKey(routingName))
                    {
                        throw new Exception(string.Format("Controller's routing name '{0}' is ambigious.", routingName));
                    }
                    if (ControllerToRoute.ContainsKey(controllerName))
                    {
                        throw new Exception(string.Format("Controller's regular name '{0}' is ambigious.", routingName));
                    }
                    RouteToController.Add(routingName, controllerName);
                    ControllerToRoute.Add(controllerName, routingName);
                }
            }
        }
    }
}

Uvedená ukázka je jen takový návod “jak na to”. Např. pokud máme url ve tvaru “langCode/controller/action“, tak můžeme (de)lokalizaci provádět podle hodnoty langCode, čímž už získáváme ony avizované lokalizované url.

Nyní tedy máme napsanou vlastní třídu routovacích pravidel a už nám zbývá jen vytvořit konkrétní pravidla, typicky v metodě Application_Start v souboru Global.asax.cs. Nemůžeme použít extenzní metodu MapRoute, protože ta používá natvrdo třídu System.Routing.Route, ale i tak se nejedná o nic složitého:

routes.Add("Default", new LocalizableRoute("{controller}/{action}/{id}", new MvcRouteHandler())
{
    Defaults = new RouteValueDictionary { { "controller", "domu" }, { "action", "Index" }, { "id", "" }, },
});

Generický parametr

Začněme tím víc typovým způsobem – máme za úkol vytvořit instanci typu, jenž máme předán jako parametr generiky. Na generické parametry můžeme klást různé požadavky (za klíčovým slovem where) a jedním z nich je existence bezparametrického konstruktoru (new()). Konstrukce instance třídy předané jako generický parametr vypadá takto:

class ClassFactory<T> where T : new()
{
    public static T Create()
    {
        return new T();
    }
} 

To je z hlediska designu docela pěkný, silně typový, přístup s kontrolou existence bezparametrického konstruktoru. Podívejme se teď, jaký CIL kód nám z této metody vypadl:

Jak vidno, volá se statická generická metoda System.Activator.CreateInstance<T>. Tato metoda je úplně normální a můžeme ji tudíž použít na vytvoření instance kdykoliv, když máme k dispozici generický typ. Můžeme ji použít ale i tehdy, když nemáme na generickém parametru specikováno omezení new(), což může vyústit ve výjimku za běhu. Proto doporučuji navrhnout aplikaci tak, abychom se přímémo volání metody CreateInstance<T> vyhnuli (tzn. nějak zajistit omezení generického parametru). Ve stejném duchu se vyjadřuje i dokumentace k této metodě.

System.Type

Druhým způsobem, jak se k nám může dostat informace o třídě, jejíž instanci máme vytvořit, je pomocí třídy System.Type. Tuto třídu můžeme získat různými způsoby:

Type t1 = typeof(TestClass); // přímo z typu
Type t2 = someObject.GetType(); // z kterékoliv instance lze získat aktuální typ
Type t3 = System.Reflection.Assembly.GetEntryAssembly().GetType("Test.TestClass"); // ze stringu!
Type t4 = typeof(ClassFactory<>).MakeGenericType(t1); // získání typu generiky s konkrétním generickým typem 

A jak vytvořit instanci takové typu, o němž máme informaci v podobě instance třídy System.Type? Takto

// jednoduše
var i1 = Activator.CreateInstance(t1);
// složitěji - získáme konstruktor a zavoláme ho
var i2 = t1.GetConstructor(Type.EmptyTypes).Invoke(null); 

Výhodou těchto dvou řešení je to, že ho můžeme použít i pro konstruktory s parametry. Nevýhodou je ukrutná pomalost. Proto uvedu ještě jedno řešení, které spočívá v tom, že si dynamicky vygenerujeme CIL kód, který vytváří instanci třídy:

// vytvoříme dynamickou metodu
var dynamicMethod = new DynamicMethod("blabla", t1, Type.EmptyTypes);
var ilGenerator = dynamicMethod.GetILGenerator();
// vygenerujeme do ní kód, který zavolá bezparametrický konstruktor
ilGenerator.Emit(OpCodes.Newobj, t1.GetConstructor(Type.EmptyTypes));
// a vrátí jeho výsledek
ilGenerator.Emit(OpCodes.Ret);
// vycucneme si delegáta na dynamickou metodu
var creator = (Func<object>)dynamicMethod.CreateDelegate(typeof(Func<object>));
// a voláme delegáta, který nám vrací instance
var instance = creator(); 

vlko mi v komentáři připomněl ještě jednu možnost, jak vytvářet instance (díky!). Je to podobné jako předchozí generování CILu, ale je to trošku abstrahovanější, modernější. Vygenerujeme takovou lambda expression, která bude vracet novou instanci, a tuto lambda expression zkompilujeme na delegáta. Kdybych udělali ale toto, tak dostaneme výjimku za běhu:

var lambdaCreator = (Func<object>)System.Linq.Expressions.Expression.Lambda(System.Linq.Expressions.Expression.New(typeof(TestClass))).Compile(); 

Konkrétně tuto výjimku: Objekt typu System.Func`1[CreateInstanceTest.TestClass] nelze přetypovat na typ System.Func`1[System.Object].. Problém je v tom, že jazyk C# 3.0 nepodporuje kontravarianci generických typů, tudíž nelze přetypovat Func<TestClass> na Func<object>. V C# 4.0 už toto bude bez problémů možné.
Aby vytváření instancí pomocí zkompilované lambda expression fungovalo i v C# 3.0, musíme vygenerovat takovou lambda expression, která bude přímo vracet Func<object> – tudíž musíme nově vytvořenou instanci ještě v lambda expression přetypovat na object:

var lambdaCreator = (Func<object>)System.Linq.Expressions.Expression.Lambda(System.Linq.Expressions.Expression.Convert(System.Linq.Expressions.Expression.New(typeof(TestClass)), typeof(object))).Compile();
var instance = lambdaCreator(); 

Místo metody Convert můžeme použít také ConvertChecked nebo TypeAs, ale Convert je podle mých jednoduchých měření nejefektivnější.

Výkon

Na závěr uvedu jednoduché výkonové srovnání jednotlivých metod, včetně zpomalení oproti běžnému volání new. Měření není nikterak přesné a má sloužit je k orientaci v problematice. Vždy jsem vytvářel 1024 * 1024 instancí jednoduché public třídy:

Jak vidno, Activator.CreateInstance<T>() a new T() je stejně rychlé, což jsme si již vysvětlili. Negenerická metoda Activator.CreateInstance() stejně jako přímé volání konstruktoru o dost pomalejší než klasické vytvoření pomocí new. Tomu se přibližuje jen dynamicky vyemitovaný CIL kód, resp. zkompilovaná lambda expression.

Jak jsem psal, toto měření proběhlo pro vytváření public třídy. Pokud ale změníme viditelnost třídy na internal, dostáváme jiná čísla:

Co k tomu říci? Snad jen – zajímavé
Pro úplnost přikládám testovací kód.

Závěr

Pokud máme vytvářet instanci typu, jehož přesný typ není v době kompilace znám, je z hlediska výkonu (nepočítaje start-up) nejvýhodnější využít možnosti generování CIL kódu. Pokud chceme takto použít konstruktor s parametry, je to také možné, ale vytváření dynamické metody již bude složitější.
Upřednostnění metody s generováním CILu platí i pro situaci, kdy máme typ k dispozici ve formě generického parametru s omezením new(). Bude to rychlejší než volání new T(). Omezení na generický typ bych ale určitě nechal, abychom se nepřipravili o kontrolu během kompilace.
No a pokud nechceme toto vůbec řešit, můžeme využít třeba služeb nějakého IoC/DI kontejneru