Založit si Twitter účet a třeba jen pasivně ho sledovat je vhodný doplněk k RSS. Velkou výhodu vidím v tom, že se k člověku (pokud sleduje ty správné lidi) dostanou i věci z blogů, které by si do RSS sám nedal. Přečíst si o tom, jak řešit třeba nějaký specifický problém v Javě může člověka někam posunout…třeba k tomu, aby si uvědomil, jak je C# super

Je to trošku podobný případ jako když člověk začal používat jako zdroj informací internet (tedy nějaký uzavřený okruh serverů) místo čtení novin. U novin se člověk dostane i k věcem a názorům, které mu v případě „soukromého vesmíru“ unikají…

Dalším zajímavým bodem je „Carry around a modern phone„. Z mého pohledu ne kvůli tomu, abyste byli free-cool-in, ale protože denodenním používám člověk lépe pochopí, co běžného uživatele trápí a jaká by naše mobilní aplikace opravdu neměla být.

Jak píše jeden komentující, přidal by dvanáctý bod – „Get a hobby.„. Já bych bodů přidal rovnou pět, aby se člověk z toho všeho programování a spol. nezbláznil a třeba nevyhořel:

1. Najděte si ženskou. Pokud už ženskou/rodinu máte, věnujte se jí/jim. Pokud jste rádi Singleton, tak choďte mezi lidi – a teď myslím lidi, ne programátory A když už chodíte jen mezi programátory, tak aspoň řešte něco jiného než programování. Vystupte ze své komfortní zóny!
2. Začněte dělat nějaký sport (ne šachy). Aspoň jednou týdně. Jestli máte odpor ke sportu, pusťte si oblíbenou hudbu do uší a běžte se svižným krokem na hodinku projít. Vaše tělo vám bude vděčné.
3. Najděte si nějaký (ideálně nepočítačový) koníček, který zaměstná jinou než „analytickou část mozku“. Začněte se učit nový cizí jazyk, vytáhněte zaprášený hudební nástroj, začněte kreslit, chodit na keramiku, …
4. Přečtěte alespoň dvě beletristické knihy. Ač se české školství vehementně snaží vybudovat v nás odpor k literatuře (aspoň já to tak vnímal), nedejte se.
5. Dbejte na svou životosprávu. Teď nemyslím, abyste se krmili jen salátama a podobnýma nesmyslama, ale snažte se jíst pravidelně a nenechávejte tělo zbytečně dlouho hladovět. Opět, vaše tělo vám bude vděčné.

A na závěr bych si dovolil jedno heslo, které mě oslovilo a možná se v něm někteří také najdete:
„Dřív jsem obdivoval lidi, kteří pracují 16 hodin denně. Teď obdivuji lidi, kteří nemusí pracovat vůbec.“

A protože se blíží konec roku, tak bych vám rád poděkoval za přízeň a popřál vše dobré do nového roku & happy coding

V krabičce „Application“ je skryta doménová logika i přístup k datům – odprostím se tedy prozatím od toho, jak je jádro aplikace implementované (DDD s ORM, Transaction Scripts, Active Record, …). Místo toho se zaměřme na to, jak je realizována komunikace mezi Aplikací a GUI – je to nějaká fasáda – vrstva rozhraní, které utváří API naší Aplikace, a nedělá tedy nic jiného, než že tupě volá Aplikaci.

Ve webovém GUI se striktně rozlišuje (a kdo to nedělá, je prasátko) mezi requesty, které provádí jen čtení (GET), a requesty jen měnícími stav (POST). Jak ví každý slušný webový vývojář, POST požadavek by neměl nic prezentovat (renderovat html) – měl by jen „nějak“ zpracovat požadovaný příkaz a říci prohlížeči, kdo mu poskytne vizuální reprezentaci výsledku (tj. na jakou stránku má udělat redirect). Tento koncept je znám jako vzor Post-Redirect-Get a vzásadě to není nic jiného než krásná implementace CQS – Command Query Separation, což je koncept, který říká, že „objekt“ by měl mít jen dva druhy metod:

• provádí výhradně změnu a nic nevrací (tj. vrací void a nemají výstupní parametry)
• nemění stav, jen čtou

Převedeno do řeči CQRS, GUI (obecně zbytek světa) komunikuje s Aplikací srkzeva Commands (první typ metody) & Queries (druhý typ metody):

Commands

Když chceme po Aplikaci něco vykonat (provést nějakou akci, která změní stav), pošleme směrem k Aplikaci tzv. Command. To je obyčejná třída bez metod, jen krabička na data (DTO), jejíž properties představují parametry příkazu, který chceme provést.

Commandové API Aplikace je triviální – je to jediný interface, který má jednu metodu: void HandleCommand(ICommand command)
V zájmu minimalizace requestů se často přidává druhá metoda HandleCommands, jejíž účel si laskavý čtenář jistě domyslí
Toto univerzální rozhraní má jediný úkol (často delegovaný na kontejner) – předat Command do odpovídajícího Command Handleru, který provede jeho zpracování (ten už komunikuje přímo s Aplikací).

public interface ICommandHandler<TCommand> where TCommand: ICommand
{
  void Handle(TCommand command);
}

V čem je síla takového řešení? Protože pořád nikde nic nevracíme, nemusíme čekat na „fyzické“ zpracování příkazu, tzn. GUI zobrazí obligátní hlášku „Váš požadavek bude zpracován.“ a může vesele pokračovat dál.

Informace o zpracování

Zde vyvstává otázka, jak informovat uživatele/externí systém, že byl příkaz (ne)úspěšně zpracován (pokud ho to zajímá). Protože Command Handlery nic nevrací, musíme použít jinou komunikační cestu – v případě uživatele na e-shopu nás nepřekvapí klasické poslání mailu. Jiný způsob (pokud chceme informovat uživatele interaktivněji) je ten, že ICommand obsahuje property Id typu Guid, kterou může GUI nastavit a na základě tohoto identifikátoru požadavek trackovat. Konkrétní způsoby realizace jsou mimo rozsah toho článku, ale pěkným řešením je notifikace webového serveru o zpracování Commandu skrze Message Bus a následně nějaká forma (pseudo)persistentního spojení mezi webovým serverem a prohlížečem (pollování, WebSockets, …).

Benefity

Přijde vám posílání Commandů zbytečně složité a nestojí podle vás za to, že máme díky němu možnost zadávat příkazy z GUI asynchronně? Souhlasím! Síla tohoto řešení je totiž v tom, že nám umožní rozložit zátěž v čase (tj. rozmělnit špičky v zátěži) a řešit výpadky aplikace. Těchto neocenitelných benefitů docílíme tím, že GUI nebude Commandy posílat přímo naší aplikaci, ale bude je jen předávat prostředníkovi (Message Bus, Command Bus, Message Queue), který je bude dále přeposílat naší aplikaci.
Pokud zrovna nebude naše aplikace dostupná, tak uživatel v GUI nedostane chybovou hlášku, ale požadavek (Command) se uloží do fronty, a jakmile aplikace naskočí, prostředník to zmerčí, přepošle Command aplikaci a ta ho zpracuje. Uživatel tak dostane mail s potvrzenou objednávkou maximálně o chvilku později a není obtěžován momentálních chvilkovým výpadkem aplikace.

Onen prostředník (MessageBus) by pro nás měla být (podobně jako databáze) jen infrastrukturní záležitost (100% dostupná) a typicky ji nebudeme implementovat sami, ale použijeme nějaké existují řešení – v případě vlastní infrastruktury např. MSMQ nebo RabbitMQ, v případě cloudu např. Azuří Service Bus nebo Amazoní Simple Queue Service.

Kompatibilita

Když se na tento způsob interakce GUI a Aplikace podíváme s odstupem, zjistíme, že to není o tolik složitější než klasický přístup. Místo každé hlavičky metody budeme mít třídu reprezentující Command a tělo metody přesuneme do metody Handle odpovídající Command Handleru (nic nebrání, aby jedna třída implementovala více podobných Command Handlerů).

public OldFashionedFacade: IOldFashionedFacade
{
  public void OrderProduct(Product product, Customer customer)
  {
    // handle using Application
  }
}

public class OrderProductCommand : ICommand
{
  public Product Product { get; set; }
  public Customer Customer { get; set; }
}

public class OrderProductCommandHandler: ICommandHandler<OrderProductCommand>
{
  public void Handle(OrderProductCommand command)
  {
     // handle using Application
  }
}

Za povšimnutí stojí to, že parametry staré metody přejdou v properties třídy reprezentující Command. Pokud chceme mít nadále dostupné old-fashioned API (např. si nemůžeme dovolit měnit takto zásadně API), můžeme jednoduše nagenerovat toto API z Commandů. Jednoduše pro každý Command vygenerujeme jednu metodu fasádního interface, properties Commandu překlopíme na parametry této metody a metoda bude vevnitř jen volat univerzální Handle. Ale ani tady se nemusíme zastavit – můžeme např. nagenerovat i metody se sufixem Sync, které zajistí, že Command bude okamžitě zpracován místo zařazení do fronty v MessageBusu (někdy se to může hodit).

Jak vidno, zadávání požadavků do Aplikace přes Commandy nám přináší neuvěřitelné možnosti a v tomto řešení vidím jediný problém – je těžké rozhodnout, který kód je součástí Aplikace (a měl by tedy být uvnitř Aplikace) a který kód je jen infrastrukturní (a měl by tedy být v Command Handleru). Rozhodně do Command Handleru patří konverze typů, základní validace a autorizace. Zbytek je na vašem rozhodnutí…

Queries

Dotazovací část fasády Aplikace zůstane zvenku prakticky stejná – pořád se bude jednat o synchronní volání metod, protože uživatel chce vidět produkty v gridu okamžitě. Navenek to tedy mohou zůstat klidně fasádní služby, které budou volat NĚCO vespod. Pokud jste čekali, že to NĚCO bude Aplikace, musím vás zklamat. Prezentovat uživateli data, která prošla skrze Doménovou vrstvu, to bývá jeden z největších problémů nejen z hlediska výkonu (načtete celou entitu a pak zobrazíte jen příjmení) tak z hlediska čistoty kódu – pokud jste např. přidali entitě Person readonly property DisplayName jen proto, že ji potřebujete v GUI, tak si rovnou dejte facku

Takže co bude to, co budou volat metody fasádních služeb (Queries) ? Nejefektivnější je sahat přímo do databáze – v případě .NET přes ADO.NET, příp. nějaký jednoduchý mapper (např. Dapper). Ať se vám to může při prvním pohledu zdát jakkoliv zvrhlé, po několika měsících musím uznat, že je to dobrá cesta a nevede k masivní duplikaci kódu, jak by to mohlo na první pohled vypadat.

Jak vidíme, de facto teď máme nad jednou persistentní vrstvou dvě aplikace – jedna se stará o zpracování Commandů a druhá o co nejrychlejší prezentaci dat uživateli (via Queries). Queries teď dělají to, že spouští (vysoce optimalizované) dotazy nad databází, které tahají jen ta data, která jsou opravdu potřeba.

Když budeme mít ale jen jednu databázi a aplikace zrovna bude pod velkým write-loadem (hodně Commandů), odnesou to Queries vyšší latencí – proto může být dobrý nápad rozdělit databázi na dvě:

OpDB (Operational Database) je běžná databáze v 3NF+, ke které Aplikace přistupuje běžným způsobem – např. pomocí full-featured ORM – v .NET se dá za něj považovat asi jen NHibernate, Entity Framework teprve bloumá okolo nádraží

K ReadDB přistupují Queries co nejpříměji, např. přes nějaký zmiňovaný lightweight-ORM. Účelem této databáze je umožnit servírovat data uživateli co nejrychleji. Nejrychlejší by bylo mít pro uživatele předrenderovanou celou stránku (HTML), jen ji přečíst na jeden request z databáze (přes Query, resp. ReadApp) a přes webový server poslat do prohlížeče. To je poněkud extrémní řešení, proto se spokojme s tím, že budeme schopni na jeden request (a řekněme do desítek ms) získat všechna data potřebná pro zobrazení celé stránky, tedy „ViewModel“ stránky. ViewModel můžeme v databázi mít uložen jako Json, XML, DTO serializované do BLOBu, jak je libo. Jediná podmínka by měla být, že jsme schopni získat všechna data na jeden jednoduchý dotaz (žádný join!).

Správně, ReadDB není nic jiného než předem napopulovaná cache, po které nechceme nic jiného než vytáhnout surová data na základě nějakého ID. Proto ReadDB nemusí být vůbec klasická relační databáze – může to být klidně NoSQL databáze! A naše aplikace pak bude cool!

Synchronizace

Je nabíledni, že musíme ReadDB průběžně upravovat podle toho, jak se mění OpDB (~synchronizovat). To se typicky děje (opět) pomocí Message Busu, kdy při úpravě Doménového modelu vyvoláme událost, že došlo k nějaké změně (ProductChanged). Kdokoliv (tedy včetně ReadApp) má pak šanci tuto událost odchytit a poupdatovat podle ní odpovídající předpřipravené ViewModely apod.

Pokud ale nechceme udělat takový velký skok v používaných technologiích, není nic ztraceno. Můžeme uvažovat o dvou databázích jen z konceptuálního hlediska, fyzicky budeme mít jen jednu klasickou relační databázi. Jak už jsem psal, na úplném začátku jsme v situaci, kdy v Queries píšeme dotazy nad OpDB. Abychom dosáhli rozumného výkonu, musíme i v tomto řešení začít duplikovat data – k tomu slouží v klasických relačních databázích indexy. Takže máme databázi s indexy, klasika.

Prvním krokem k možnému budoucímu přesunu na více fyzických databází je to, že vytvoříme pohledy (Views). Prakticky sice budeme dělat pořád to samé, ale dotazy už budou ve své finální podobě („SELECT * FROM ViewModel1 WHERE Id = @Id„) a nebudeme na ně tak muset v dalších krocích sahat.

Další iterací je to, že pohledy budou materializované. Pokud to náš DB stroj neumí, můžeme si je implementovat sami – jednoduše vytvoříme místo pohledů tabulky se stejnou strukturou. Pak si vytvoříme triggery nad původními tabulkami a podle zápisů do nich budeme upravovat naše materializované pohledy.
Je zřejmé, že se nám tím zpomalí zápis, ale čtení bude bleskurychlé – takže konkrétní řešení závisí i na tom, jaký je ve vaší aplikace poměr čtení/zápis (nejčastěji to prý bývá 80 % vs. 20 %).

Pokud budeme chtít ReadDB a OpDB skutečně fyzicky rozdělit (a pokud neumíme zajistit spouštění triggerů přes více DB strojů), musíme synchronizaci přenést o úroveň výše. A tím se dostáváme zpět k výše zmiňované synchronizaci přes události (Events), které můžeme vyvolávat tam, kde to bude pro naši aplikaci nejvhodnější – v DALu, v Doméně nebo třeba po úspěšném zpracování Commandu…

UI

Jak je vidět z posledního obrázku, naše GUI teď prakticky pracuje nad dvěma aplikacemi – jedna zajišťuje načítání dat a druhá zpracování dat. Načítání dat zůstává prakticky stejné jako v případě klasické (non-CQRS) aplikace, ale rozdíly ve zpracování dat jsou markantní. Už nejsme schopni garantovat to, že po odeslání objednávky ji zákazník hned uvidí v nějakém seznamu, protože třeba příkaz ještě není zpracován nebo ještě nestačila proběhnout synchronizace ReadDB. A tomu je třeba přizpůsobit koncepci uživatelského rozhraní, příp. si více pohrát s aplikací. V části o Commandech jsem se např. zmiňoval o možnosti trackování stavu Commandu…

V souvislosti s CQRS se často mluví o tzv. Task-Based UI, což je alternativa k běžnému CRUD UI. Není to něco, co je v CQRS povinné, ale považuji to za zajímavý koncept, proto ho chci letmo zmínit.
Klasické CRUD UI se vyznačuje tím, že umožňuje vytvořit entititu, upravit ji a příp. ji smazat. Problém je, že když voláme metodu Change, tak tím vůbec nevyjadřujeme záměr, proč tak činíme.
Bylo by mnohem lepší, kdychom měli připravené Commandy, které by vyjadřovaly, že např. měníme adresu zákazníka, protože se stěhuje (a podle nové adresy mu doporučit novou výchozí prodejnu), že měníme příjmení zákazníka, protože se oženil/vdala/registroval(a), že mažeme zákazníka, protože zemřel atd.
A pro tyto specifické tasky pak budeme mít specifické UI – Task-Based UI.
S problematikou ukládání takových informací do databáze souvisí Event-Sourcing, ale o tom třeba někdy jindy…

Co z toho?

CQRS je velmi zajímavý vzor, díky kterému jsem se dozvěděl o spoustě zajímavých konceptů, z nichž některé úspěšně používám v praxi. Ty nejzajímavější koncepty (MessageBus, ReportingDatabase) jsem se pokusil nastínit v tomto článku a věřím, že vás mohou inspirovat k dalšímu studiu CQRS a příp. i vylepšení vašich aplikací.

O CQRS není problém vygooglit spoustu materiálů (a možná se vás už ani Google nebude ptát „Did you mean CARS?“ ) – doporučuji především materiály od Grega Younga, Udiho Dahana a Rinata Abdullina.

SuperModel

V předchozím řešení jsme od ViewModelu, který reprezentuje stránku s widgety, požadovali, aby implementoval rozhraní IViewModelWithWidgets. Pokud ale v našem projektu widgety podporuje drtivá většina stránek, nemusí být toto řešení nejvhodnější. Nechceme totiž v zájmu DRY opakovat definici property Widgets v každém ViewModelu, takže nakonec stejně skončíme u nějakého bázového ViewModelu (který jako jediný tuto property implementuje) a to se nám už nemusí líbit a můžeme začít šilhat po jiném řešení. Přitom ale nemusíme nutně slevovat z našeho požadavku, aby byla celá stránka reprezentována jedním „ViewModelem“.

Data pro celou stránku jsou totiž ve skutečnosti reprezentována třídou ViewDataDictionary, která je v Controlleru i v šabloně dostupná jako property ViewData. Jak již název napovídá, ViewDataDictionary není (zjednodušeně řečeno) nic jiného než Dictionary ze stringu na object, který má ale navíc další properties – a nejvíce na očích je právě property Model, ve které máme typicky instanci našeho ViewModelu.

Vhodnějším řešením, které nás už nebude nabádat k vytváření super-ViewModelu, je tak ukládání dat pro widgety pod nějakým klíčem přímo do ViewData. Kód v akčním filteru (metoda OnActionExecuted) se nám tak ztenčí na pouhé přímé přiřazení do ViewData. I kód v šabloně bude jednodušší – omezí se na zjištění, zda je ve ViewData obsažen požadovaný klíč.

Úplně nám tak odpadne potřeba zavádět nějaká infrastrukturní rozhraní jako v řešení z předchozího článku…

Ajaxizace

Uživatele našeho webu bude asi typicky zajímat především hlavní obsah stránky a nechce být zdržován tím, že bude muset čekat o chvilku déle než se načte nějaký zpropadený widget, který ho třeba v danou chvíli vůbec nezajímá. Jaké máme možnosti, když se vzdáme řešení s použitím Action Filterů?

Od ASP.NET MVC 2 máme k dispozici helper metody Html.Action a Html.RenderAction, pomocí kterých můžeme provést jakýsi Sub-Request. Dojde tedy k zavolání dané akční metody a spuštění vráceného ActionResultu (jako v případě běžného requestu). Výsledek můžeme získat buď ve formě stringu (Html.RenderAction) nebo je výsledek vyrenderován přímo na místo, kde voláme Html.Action. Toto je velmi silná zbraň a díky ní můžeme prezentační logiku koncipovat zcela jinak.

Ideální mi přijde situace, kdy máme pro každý widget jednu akční metodu a k ní odpovídající šablonu (~ascx~Partial View). Mohli bychom mít jeden „velký“ Controller jen pro akční metody widgetů, ale bude lepší mít pro každý widget samostatný Controller – widgety totiž mohou být interaktivní (tj. potřebovat další akční metody pro dodatečnou funkcionalitu) a pravděpodobně budou mít zcela rozdílné závislosti.

Pokud máme pro widget samostaný Controller a samostatnou šablonu, máme ho krásně separovaný. Úkolem hlavní stránky pak bude pouze zajistit volání Html.[Render]Action pro každý widget.

Separace nám přináší i další výhodu – volání akční metody je skvělý kandidát na kešování – můžeme využít standardní atribut OutputCache.

Nyní jsme ale stále v situaci, kdy se celá stránka načítá během jednoho requestu – ajaxizace je ale velmi jednoduchá! Pokud totiž akční metodu neoznačíme atributem ChildActionOnly, můžeme ji volat i samostatně v rámci normálního requestu (samozřejmě musíme zajistit, aby se k ní dalo doroutovat).
V hlavní stránce, která dosud volala Html.[Render]Action, se bude nyní generovat kód, který zajistí, že se widgety dotáhnou pomocí samostatných Ajax requestů (např. s využitím data atributů).

Pokud chceme minimalizovat počet Ajax requestů, můžeme udělat jednu pomocnou akční metodu, která spustí akční metody požadovaných widgetů – tím se dostaneme na jeden request pro hlavní stránku a druhý request pro widgety.

Závěr

V předchozím článku jsem nastínil způsob implementace widgetů, který byl oblíbený v době první verze ASP.NET MVC. V první části toho článku jsem ukázal jeho vylepšení, které nás nenutí používat bázové třídy pro ViewModely a nejen díky tomu je flexibilnější a méně invazivní.

Za nejlepší řešení v současné době ale považuji variantu s Html.[Render]Action, která přináší mnohem větší míru modularity a jako (příjemný) důsledek snadné kešování a podporu pro asynchronní načítání widgetů v samostatném requestu.

Každý projekt si ale žádá svoje a tyto dva články rozhodně nepopisují všechny možnosti, jak je možné widgety v ASP.NET MVC implementovat. Věřím ale, že články mohou posloužit jako inspirace při implementaci widgetů ve vašem projektu…

Data pro widgety

Moje filozofie je taková, že ve ViewModelu (který se vrací v akční metodě pomocí return View(viewModel);) musí být všechna data potřebná pro rendering celé stránky – tedy „hlavní obsah“ i data widgetů.

Na úrovni Controlleru tak musíme zajistit, že načteme data pro všechny widgety, které budeme zobrazovat. Ano, už v Controlleru musíme vědět, co přesně budeme chtít vykreslovat – tak to má být – rozhodně bychom neměli takové rozhodnutí nechávat až do View!

Widgety ale nejsou „tím hlavním“ co chceme v akční metodě dělat – to je něco jiného – např. v případě blogového systému načtení informací o článku (text, autor, …). Přidávat ručně kód pro načítaní widgetů do každé akční metody samozřejmě nebudeme. Takový úkol lze elegantně řešit pomocí aspektů, které jsou v ASP.NET MVC dostupné formou Action Filterů. Implementujeme tedy v Action Filteru metodu OnActionExecuted, která se volá po provedení akční metody.

Jak ale zařídit, abychom mohli v této metodě uložit data pro widgety do ViewModelu? Jednoduše si vytvoříme rozhraní IViewModelWithWidgets, které musí implementovat každý ViewModel, jenž odpovídá stránce, na níž chceme vykreslovat widgety. Zde záleží, jestli máme widgety pevné nebo např. uživatelsky konfigurované.
V prvním případě můžeme mít dílčí ViewModely pro widgety přímo jako properties rozhraní IViewModelWithWidgets.
V druhém případě (který budu uvažovat dále) bude lepší mít jen jednu property typu IEnumerable<IWidget> nesoucí data pro všechny widgety. Rozhraní IWidget by mělo obsahovat minimálně property string PartialViewName – můžeme ale přidat třeba informace o pořadí widgetů apod.

Kostra Action Filteru může vypadat takto:

public void OnActionExecuted(ActionExecutedContext filterContext)
{
  if (!(filterContext.Result is ViewResultBase))
  {
     return; // we will not render a View
  }
  var vm = ((ViewResultBase)filterContext.Result).Model as IViewModelWithWidgets;
  if (vm == null)
  {
    return; // we don't want to render widgets
  }
  vm.Widgets = InjectedWidgetProvider.GetWidgetsForCurrentUser();
}

Atributem můžeme odekorovat jednotlivé metody, celé Controllery, příp. zaregistrovat Action Filter jako globální nebo ho servírovat pomocí vlastního Filter Provideru (pak ho nezapomeňte zaregistrovat). Poslední možnost doporučuji zejména tehdy, když potřebujete řídit životnost Action Filteru nebo do něj injectovat nějaké závislosti (např. připojení do databáze na přečtení nakonfigurovaných widgetů pro přihlášeného uživatele).

Vykreslení

Při použití ASPX enginu (ne-Razor) vyřešíme vykreslení widgetů elegantně pomocí Master Pages (když si ve Visual Studiu vytvoříte nový ASP.NET MVC 3 Web Application, tak ten Master Pages používá).
To znamená, že máme soubor Site.Master, který obsahuje „šablonu“, jak má vypadat celá stránka. V této „šabloně“ máme díry, jejichž obsah se mění – takže nějaký ContentPlaceHolder pro hlavní obsah, pro menu, pro nadpis stránky apod.
V konkrétním View (např. Detail.aspx) pak pomocí atributu MasterPageFile určíme, jaká Master Page se použije (často máme v projektu jen jednu – Site.Master) a naším úkolem je dodat obsah pro ContentPlaceHoldery.

Ale zpět k našim widgetům. Kód v Site.Master bude přímočarý – zjistíme, zda se mají widgety renderovat, a pokud ano, tak je na nějakém vhodném místě (třeba uvnitř nějakého divu) vykreslíme:

if (Model is IViewModelWithWidgets)
{
  foreach(IWidget widgetViewModel in ((IViewModelWithWidgets)Model).Widgets)
  {
     Html.RenderPartial(widgetViewModel.PartialViewName, widgetViewModel);
  }
}

Pro každý widget pak budeme mít Partial View (ascx), které bude mít Model odpovídajícího typu (implementující rozhraní IWidget).

Závěr

Co jsme tedy museli udělat:

• Připravit si datový model, tj. zavést si rozhraní IWidget a IViewModelWithWidgets.
• ViewModely pro widgety musí implementovat rozhraní IWidget.
• ViewModely pro stránky, které obsahují widgety, musí implementovat rozhraní IViewModelWithWidgets.
• Zajistit naplnění kolekce Widgets na úrovni Controlleru – k tomu nám skvěle poslouží Action Filter.
• Vytvořit Partial View (ascx soubor) pro každý widget a zajistit jeho vykreslení v Site.Master.

Dle mého názoru tedy nic extrémně složitého – ViewModel a Partial View pro widgety jsou nutné minimum (proto to děláme) a infrastrukturního kódu není tolik – prakticky jen načtení dat v Action Filteru a vykreslení widgetů v Site.Master.

V praxi můžeme chtít toto řešení dále rozvinout – např. načítat widgety asynchronně pomocí AJAXu. Ani to ale není nic složitého…
[navazující článek]

Co to je?

Především je důležité zdůraznit, co NoSQL není – rozhodně to není NO SQL, tedy trendy odmítání relačních databází. Zkratka NoSQL znamená Not Only SQL, tedy uvědomění si toho, že relační databáze není jediná možnost řešení persistence, že existují i alternativy, které mohou být v některých případech vhodnější.

U rozsáhlejších aplikací pak můžeme dojít k tomu, že na některá data je vhodná relační databáze, na jiná NoSQL databáze a na další data úplně jiná NoSQL databáze. Tento pragmatický přístup, kdy se mixuje použití více databází v jednom projektu, se často označuje jako polyglot persistence.

NoSQL databáze vznikaly (a vznikají) jako řešení reálných problémů – není to tedy bláznivý výmysl akademiků odtržených od reality, ale vysoce praktická záležitost. Zrod mnoha NoSQL databází je spjat s projekty, které se musely vypořádat s obrovským množstvím dat – Facebook (Cassandra), Google (BigTable), Amazon (Dynamo), LinkedIN (Voldemort) atd.

Použití NoSQL databáze může mít ale smysl i tehdy, pokud máme méně dat (které by v pohodě zvádla relační databáze) – třeba protože nějaká NoSQL databáze nabízí datový model, který je pro naši aplikaci přirozenější.

Ale zpět k úvodní otázce. NoSQL databáze je software pro perzistenci dat, který je alternativou ke klasickým relačním databázím (nic objevného). NoSQL databází existuje mnoho a dají se rozdělit z mnoha hledisek. Ve velmi specifických případech může dávat smysl vyvinout i vlastní NoSQL databázi (ale myslete na NIH).

Kdy použít NoSQL

Rozhodnutí, zda použít místo ověřené relační databáze neznámou NoSQL databázi, není jednoduché, a hlavně to není rozhodnutí jen technické, ale i ekonomické.

NoSQL databáze např. často nemají takové možnosti dotazování jako relační databáze. Zkuste se třeba zamyslet nad tím, jak by ovlivnilo vaši aplikaci, kdyby jedinou podporovanou DB operací bylo uložení řádku a jeho načtení podle nějakého ID (nepřeháním!). To vede k tomu, že je na vaši aplikaci přenášena odpovědnost (např. generování sekundárních indexů), kterou jste dosud považovali za samozřejmou součást databázového enginu. Použití NoSQL databáze tak často znamená kompletní redesign celé aplikace, takže hodně učení a práce pro aplikační programátory (kteří nepracují zadarmo).

Většina dnešních programátorů vyrůstala ve světě, kde jedinou možností uložení dat byla relační databáze. Umí tak s ní dobře pracovat (v čemž jim pomáhají léty vyladěné tooly), jsou na ni schopni napasovat jakýkoliv model a už při úvodním seznamování s novým projektem jim v hlavě automaticky naskakují tabulky a vazby mezi nimi. Takže stojí za zvážení, zda se opravdu vyplatí investovat čas (~peníze) do učení diametrálně odlišných technologií a zda nemůže být ekonomičtější použít léty ověřené relační databáze namísto nové sexy NoSQL databáze.

Tím nechci říct, že se má absolutně kašlat na vzdělávání a inovaci, ale situace na trhu práce je tristní a ne každý má to štěstí (já ano ), že pracuje s bandou nadšených vývojářů, kteří čtou blogy, zajímají se o novinky v oboru a po večerech si zkouší nové technologie. Mnohdy člověk musí pracovat s lidmi, pro které je programování jen způsob obživy, odpracují si svých 8 hodin a tím to pro ně končí. A dělat s takovýmto týmem projekt, který používá NoSQL databázi, může být nákladné.

Náklady spojené s přechodem na NoSQL databázi se ale týkají celého týmu. Také vaši admini si budou muset umět poradit s novým SW v infrastruktuře, naučit se ho spravovat, zálohovat, tunit atp.

Takže?

Co jsem chtěl říct tímhle zamyšlením? NoSQL je zajímavá alternativa k zavedeným relačním databázím a rozhodně má své místo na trhu a proto doporučuji se o NoSQL databáze zajímat a nějaké si zkusit osahat. Pokud si proti nějaké NoSQL databázi zkusíte napsat jednoduchou aplikaci, neuvěřitelně vám to rozšíří obzory.

Nepoužívejte ale NoSQL databáze jen protože je to cool, protože by to mohlo být lepší nebo protože je používá konkurence. Řiďte se rozumem, ne emocemi. Dobře si spočítejte, co vám NoSQL přinese a jaké budou náklady. Pokud se už pro NoSQL rozhodnete, tak myslete na to, že se nemusíte úplně vzdávat pohodlné relační databáze – v projektu nemusíte používat jednu jedinou databázi…

Tato pozice již není volná, ale máme v AVASTu jiné neméně zajímavé pozice pro .NET programátory, takže se mi v případě zájmu neváhejte ozvat.

A o jakouže práci se to jedná? Spolu se mnou, Tomášem a částečně AlenKou byste spolupracoval(a) na systému pro podporu chodu naší virové laboratoře, tzn. softwaru pro zpracování velkého množství vzorků z různých zdrojů, jejich automatické zpracování, přidělování analytikům, podporu pro vytváření nových virových definic (příp. samostatné tooly), reporting apod.

Vaším denním chlebem by tak byl C#, (T-)SQL, HTML+JS, vše podle aktuálních potřeb. Zastáváme totiž názor, že než mít specialistu jen na jednu věc (databáze, web), je lepší, aby se vývojář staral o vertikální výsek projektu, tj. aby šel se svou částí kódu od databáze, přes aplikační server až po nasazení a podporu. Přirozeně, každý jsme jiný, každého baví něco jiného (a tak se o to víc zajímá), takže zde funguje výměna zkušeností, společné Utils knihovny atd.

Pozornému čtenáři mého blogu asi netřeba zdůrazňovat, že máme rádi nové technologie (pokud má jejich použití smysl) a rádi děláme věci pořádně. Příkladem budiž použití NoSql databáze Cassandra, testování (to opravdu není pravidlem v každé firmě) nebo nově integrační server.

Co očekáváme od uchazeče?

• perfektní znalost C# (minimálně verze 3)
• perfektní znalost .NET Frameworku (minimálně verze 3.5) – kromě core především ADO.NET, ASP.NET a WCF
• zkušenosti s ASP.NET MVC
• dobrou znalost MS SQL (2008)
• praktickou znalost návrhových vzorů (tj. umět je správně aplikovat v praxi, ne je umět vyjmenovat)
• znalost základních algoritmů a jejich složitostí (opět umět využít při rozhodování během řešení úkolu)
• zkušenosti s psaním testů
• obecný rozhled v SW technologiích, tj. nežít jen v MS bublině, vědět co je heap, stack, COM, serializace, tušit jak může fungovat Garbage Collector, jak funguje TCP, HTTP, vědět proč pařez nemůže býti stromem atd. (prostě základy, co musí každý programátor znát)
• zájem o nové technologie, přístupy a postupy
• …ale i základní znalost starého dobrého čistého C (schopnost napsat/upravit jednoduchý program v C)
• vystudovaná slušná technická univerzita je dobrým předpokladem, nikoliv nutnou podmínkou (tou je znalost metodik UTFG a RTFM)

Technický skill ale není vše, takže očekáváme i rozumné osobnostní rysy, především komunikativnost (je potřeba komunikovat se zbytkem virové laboratoře) a rozumnou míru asertivity (nebát se přijít s vlastním nápadem, vylepšením nebo kritikou). Výše zmiňovaná samostatnost, smysl pro pořádek a nadšení pro práci jsou nutnou podmínkou (co si budeme nalhávat, jsme tu tak trošku perfekcionisti a zlí jazykové by řekli, že i trošku workoholici ).

Práce není možná z domova, ani na částečný úvazek, ale pracovní doba je „flexibilní“, tj. když ráno potřebujete zajít na úřad, tak se svět nezboří. Sedíme v Praze přímo na Budějovické (metro C), v krásné nové budově. Kanceláře máme různě velké, ale rozhodně nebudete sedět v openspace.

A co Vám můžeme nabídnou my (pokud Vám výše uvedené nestačí ) ?

• solidní plat
• 5 týdnů dovolené
• firemní angličtina
• 90Kč stravenky
• nealko pití na pracovišti
• příspěvek na důchodové připojištění
• nekuřácké pracoviště

Pokud Vás nabídka práce zaujala, neváhejte mi napsat!

Všechno by to šlo implementovat pomocí vzájemně provázaných skriptů, ale za šťastnější řešení (i když zavádí SPOF) považuji nasazení nějakého integračního serveru coby hlavního koordinátora všech operací. Integrační server toho pro nás může ale dělat ještě více – např. provázat buildy a verze aplikace s bug trackerem nebo issue trackerem (Bugzillou, Mantisem, Jirou, …). Integrační server se tak může stát místem, na kterém vidíte vše o projektu (a slovo integrační tak dostává další rozměr).

V tomto článku bych vám rád popsal, proč a jak jsem nasazoval integrační server já. Moc jsem toho o průběžné integraci předem nenastudoval, přistoupil jsem k věci celkem pragmaticky – cílem bylo vyřešit problémy, které mě trápili. A díky TeamCity jsem byl schopen do týdne rozjet prakticky vše, co jsem plánoval – tedy build Solution s více než 100 projekty (C# a C), spuštění unit testů, integračních testů, nasazení a spuštění akceptačních testů. Všechno samozřejmě plně automaticky, odpálené commitem do SubVersion.

Proč jsem do toho šel?

Až donedávna byl projekt, na kterém dělám, prakticky one-man-show. To mj. znamenalo, že všechno jsem měl pod palcem já – od konzistence (zbuildovatelnosti) zdrojových kódů v repository, přes spuštění a úspěšné projití všech testů až po nasazení (přes One-Click Publish). A všechny tyto kroky jsem dělal tehdy, když se mi zachtělo.
Tento stav s sebou nesl mnoho problémů – nejvíc mě pálilo občasné vypublikování neotestovaného kódu (protože touhle změnou jsem prostě nemohl nic rozbít), omylem vypublikovaná DLLka ve špatném formátu (x86 místo x64) a především zdržení spojené s ručním nasazením aplikace (před publikováním nové verze jsem ručně zálohoval aktuální verzi). O ruční synchronizaci aplikace a databázového schématu ani nemluvím. Poslední kapkou bylo to, že k projektu přišel další člověk a já si uvědomil, co všechno si musí nainstalovat, aby byl schopen projekt vůbec zkompilovat.
Zavedení continuous integration tak bylo lékem na všechny výše uvedené problémy.

Příprava

Jedna věc předem – je důležité si uvědomit, že „csproj“ soubory nejsou nic jiného než build scripty pro MSBuild a proto se nebojte do nich zasahovat ručně – ne vše jde totiž naklikat přes Visual Studio.
Prvním krokem k tomu, abyste mohli projekt zařadit do CI, je to, že projekt musí být po čistém checkoutu z repository zkompilovatelný jedním příkazem. Mým cílem tak bylo, aby fungovalo něco jako „MSBuild.exe MySolution.sln /T:Build /p:Configuration:Release„. To nebyl problém na mém vývojářském stroji, kde jsem měl nainstalované Visual Studio a knihovny třetích stran nakopírované na správná místa nebo v GACu. Na čistém build serveru to už ale tak růžové nebylo. Takže na co byste si měli dát pozor?

Pre a Post-build stepy

Pokud kopírujete v Pre a Post-build stepech nějaké dependence, které nelze jinak vyjádřit, tak zajistěte, aby v době volání příslušného stepu už existovaly – tedy zajistěte správné pořadí kompilace.
Já jsem řešil poměrně běžnou věc – mám nějakou nativní DLL knihovnu, kterou potřebuji zkopírovat do výstupního adresáře .NETího projektu. Takže jsem si pěkně naklikal ve Visual Studiu závislosti mezi projekty a kompilace krásně jela. Ale na build serveru byl problém. Závislost mezi .NETím a nativním projektem se totiž uloží jen do sln souboru (což není narozdíl od csproje build script!). V MSBuildu 3.5 by to bylo ok, protože tam si MSBuild vše pořádně očuchal a správně určil pořadí. To ale údajně způsobovalo u velkých projektů výkonové problémy (?) a tak byla tato fičura v MSBuildu 4.0 odstraněna a MSBuild kouká jen na závislosti uvedené přímo v projektových souborech. Visual studio vám ale nedovolí přidat do .NETího projektu referenci na ne-.NETí projekt, takže nelze jednoduše naklikat závislost .NETího projektu na ne-.NETtím – musíme referenci ručně dopsat do csproje. Jako bonus dostaneme ve Visual Studiu žlutý vykřičníček a warning, ale kompilace pomocí MSBuildu probíhá ve správném pořadí.

Knihovny třetích stran

Jak říká Martin Fowler – „Everything should be in the repository.„. Takže mějte ve verzovacím systému binárky knihoven třetích stran a z projektů na ně odkazujte pomocí relativních cest (nebojte se podívat přímo do csproje). Pozor si dávejte hlavně tehdy, když máte na vývojářském stroji nějakou knihovnu nainstalovanou v GACu – ve spojení s automatickým přidáváním referencí (jako nabízí třeba ReSharper) vám to může připravit nemilé překvapení (nareferencovat assembly z GACu).

Generované soubory

Pokud generujete soubory pomocí T4, tak tyto soubory musí být v repository. Jen je potřeba zajistit jejich přegenerování na vývojářově stroji – to mám udělané tak, že v pre-build stepu spouštím TextTransform.exe, ale jen pokud existuje soubor „%CommonProgramFiles(x86)%\Microsoft shared\TextTemplating\10.0\TextTransform.exe“ (instaluje se až s Visual Studiem). To zajistí, že na vývojářském stroji (tj. s nainstalovaným Visual Studiem) dojde v pre-build stepu k přegenerování T4 souboru.
Pokud se rozhodnete vyřešit T4 soubory tímto způsobem, tak reference na custom assembly nedávejte přímo do tt souboru, ale předávejte je přes parametry příkazové řádky.

Testy

Připravte se na to, že pokud máte testy napsané v MSTestu, budete muset na stroj, na kterém chcete testy spouštět, instalovat Visual Studio (pokud nechcete použít nějaký alternativní test runner).
Pokud používáte v testech DeploymentItem, tak možná narazíte na jeho trošku podivné chování při zadávání relativní cesty. Osvědčilo se mi zadávat cestu relativně k umístění sln souboru a při spuštění přes MSTest.exe pak nastavit jako runconfig soubor LocalTestRun.testrunconfig (který je ve stejném adresáři jako sln soubor).
Dále myslete na to, že tam, kde budete pouštět integrační testy, budete muset mít pravděpodobně dostupné nějaké testovací verze databází apod.

Transformace configů

Před tím, než ze zkompilovaných binárek vytvoříte instalační balíčky, můžete mít potřebu upravit nějaké konfigurační soubory v aplikaci. S .NET 4 přišly web.config transformation, které toto velmi zjednoduší. Ve webovém projektu máte klasicky soubor web.config – v něm byste měli mít nastavení, které odpovídá Debug konfiguraci (protože při debugu se nevím proč transformace neprovádějí). Dále budete mít soubor web.Release.config (Visual Studio 2010 má na jeho přidání podporu), ve kterém budou transformace připravující konfiguraci pro Release konfiguraci. Pokud máte v projektu kromě Debug a Release i další konfiguraci (např. Stage), můžete mít transformace i pro tyto další konfigurace (např. web.Stage.config).

Je možné, že budete chtít transformovat i jiný soubor než web.config (my transformujeme log4net.config). To samozřejmě není problém.
Pokud nebudete mít na build serveru Visual Studio, tak si dejte pozor, abyste si vybrali to správné řešení.

Transformaci konfiguračních souborů můžete ale samozřejmě dělat jakkoliv, třeba pomocí vlastních skriptů – na tom nevidím nic špatného.

Nejen z hlediska bezpečnosti je velmi zajímavou variantou mít v některých konfiguračních položkách místo hodnot jen placeholdery, které se naplní správnými hodnotami až při nasazení. To je velice flexibilní řešení, protože umožní nasadit jeden distribuční balíček v různých prostředích (typicky různé connection stringy).

Vytvoření instalačních balíčků

Instalační/Distribuční balíčky se zásadně liší podle typu aplikace – já se zde zaměřím jen na webové aplikace, konkrétně na vytváření balíčků, které se budou dále nasazovat pomocí nástroje MSDeploy (Web Deployment Tool).
Způsob vytvoření balíčku si můžete nastavit přímo ve Visual Studiu, v Properties dané webové aplikace. Já jsem si oblíbil možnost vytvořit balíček jako soubor zip a vytvořit ho v adresáři „Deploy/Packages“ (relativně k solution).
Důležité je, že balíčky mohou být parametrizované, což umožní výše zmiňované podstrčení správných hodnot do konfiguračních souborů až při nasazení (automaticky jsou takto parametrizovány právě zmiňované connection stringy).

Pokud chcete do balíčku přidat nějaké vlastní soubory (u mě to jsou opět nativní DLL knihovny do adresáře /bin), tak to není problém – stačí je dospecifikovat v csproji.

Jak ale vytvořit balíček z MSBuildu? Zde je opět více možností. Můžete zavolat MSBuild s targetem Package („MSBuild /T:Package„) nebo můžete nechat vytvořit balíčky ihned během kompilace pomocí property DeployOnBuild („/p:DeployOnBuild“).

Nasazení

Nasazení děláme pomocí nástroje MSDeploy, který umožňuje plnohodnotné nasazení, tj. nejen zkopírování souborů, ale i vytvoření a ovládání AppPoolu, nastavení práv, migraci databáze atd. Je třeba ho mít nainstalovaný jak na stroji, ze kterého nasazujeme, tak na stroji, na který nasazujeme. Typický příkaz pro jednoduché nasazení může vypadat nějak takto:

"%ProgramFiles%\IIS\Microsoft Web Deploy V2\MSDeploy.exe" -verb:sync
 -source:package=Packages/MyApplication.zip
 -dest:auto,computerName="https://deployTargetComputer:8172/msdeploy.axd
?site=Default Web Site",userName=%username%,password=%pwd%,authtype=basic
 -allowUntrusted

Parametry balíčku (např. výše zmiňované connection stringy) se dají nastavit intuitivně pomocí přepínače -setParam, příp. můžete podstrčit celý soubor s parametry.

Migrace databáze

Při nasazení aplikace je třeba ověřit, že okolní infrastruktura odpovídá tomu, na co byla aplikace stavěna. Pokud se zaměříme jen na databáze, tak bychom měli ověřit, že schéma v databázi odpovídá tomu, proti čemu chce aplikace pracovat.

To se typicky dělá tak, že aplikace ví verzi schématu (celé číslo), databáze má v nějaké metatabulce uloženu aktuální verzi schématu, a instalační skript je zodpovědný za to, že se zavolají migrační skripty, které zajistí upgrade (příp. downgrade) databáze podle potřeb aplikace, tj. sjednotí verzi schématu požadovanou aplikací a aktuální v databázi.

Celou tuto infrastrukturu si můžeme napsat sami (není to nic složitého), můžeme využít nějaké migrační knihovny, nebo může využít to, co nabízí Visual Studio a MSDeploy.

Můžeme začít!

Pokud jsme schopni zkompilovat projekt jednoduše ihned po čistém checkoutu z repository, máme na build serveru nainstalovány všechny potřebné věci (.NET 4, VS2010, MSDeploy, …), umíme generovat distribuční balíčky a máme připraveny skripty pro jejich nasazení, tak nám nic nebrání nainstalovat nějaký integrační server a jednotlivé části této výrobní linky v něm provázat.

Já jsem se rozhodl použít TeamCity a rozhodně své volby nelituji. O instalaci jsem se díky našemu QA starat nemusel, ale veškerou konfiguraci jsem pak dělal sám a poměrně rychle jsem se zorientoval. Předností je taktéž cena, která je pro menší a střední projekty nulová.

V každém projektu (já mám jen jeden projekt odpovídající celému solution) můžete mít (v Professional verzi, která je zadarmo, až 20) Build Configurations. Jednu Build Configuration bych označil za jednu výrobní linku, takže můžete mít třeba dvě BC z názvy „Stage“ a „Production“. Když budou tyto dvě BC téměř identické, je možné vyextrahovat šablonu a tyto dvě BC na ní založit. Parametrizaci pak provedete přes Build Parameters.

Každá BC v sobě obsahuje posloupnost Build Stepů. Prvním (implictním) krokem je checkout z repository. Další kroky jsou již plně na nás, ale TeamCity nám zde velmi vychází vstříc – jsou zde připravené „build step runnery“ pro spuštění MSBuildu, MSTestu, baťáku, PowerShellu, Antu, FxCopu…a dokonce přímo Solution (takže staší zadat cestu k solution, které chcete zkompilovat).

Dalším důležitým nastavením jsou triggery, které umožní nastavit, kdy se má BC spustit – kadý den v zadaný čas nebo po commitnutí do repository jsou samozřejmostí.

Hotovo

Týdnu, který jsem věnoval zavedení průběžné integrace, vůbec nelituji. Díky CI jsem zautomatizoval drtivou většinou věcí, které je třeba dělat při vývoji, testování a nasazování aplikace. Rozhodně ale nepovažuji současný stav za finální, protože je ještě spousta věcí, které by šly vylepšit nebo přidat – např. lepší správa konfiguračních souborů, automatický rollback po neúspěšném nasazení atd.

I současný stav je obrovským přínosem a proto vám doporučím začít s CI. Není potřeba začít hned dělat všechny věci, které zde popisuji – můžete je zavádět průběžně. Stačí začít třeba tím, že se vytvoří build server, který bude po každém commitu kontrolovat zbuildovatelnost solution – i to je velmi pěkný první krok.

Jednoduchá a univerzální poučka zní, že pokud váš unit test vyžaduje úklid (teardown), pak testovaný kód s největší pravděpodobností pracuje s globálním stavem. Potřebujete např. po skončení testu smazat nějaké soubory z disku nebo vymazat nějaké hodnoty z databáze? Pak se může jednat o integrační test a pokud si to uvědomujete, tak to může být ok. Pokud se má ale jednat o skutečný unit test, tak je něco v nepořádku. Unit test by měl totiž testovat jen jednu jednotku a to v dokonalé izolaci – a pokud nejsme schopni používaný globální stav odizolovat, pak je náš testovaný kód shnilý a měli bychom s tím něco dělat.
Máme tedy abstrahovat přístup k databázi nebo souborovému systému? V případě relační databáze jsme často díky ORM již odstíněni a slušné ORM pak není problém odizolovat a jako backend použít místo skutečné databáze jen kolekci v paměti. A u přístupu k souborovému systému není zas takový problém si vytvořit odstiňující vrstvu. Ale chápu, že to někdo může považovat za zbytečné vrstvení – pragmatickým přístupem pak může být pro takovou třídu nepsat unit test, ale jen integrační test.

Posledním, ne tak zřejmým, zdrojem globálního stavu, o kterém chci psát, je zjištění aktuálního času – vlastně to spadá do prvního zmiňované kategorie (použití globální proměnné, viz např. DateTime.UtcNow v C#), ale člověk si to tak neuvědomuje. Udělali tedy snad inženýři v Microsoftu chybu, že nám dali k dispozici aktuální čas přes globální proměnnou? Ne, jejich kód je z hlediska testovatelnosti ok. Pokud to dává smysl, klidně zavádějte globální proměnné – ale pokud chcete psát testovatelný kód, tak globální proměnné nepoužívejte napřímo. To znamená, že je vhodné z hlediska testovatelnosti odstínit údaj o aktuálním času za nějaké rozhraní ICurrentDateTimeProvider.

Jak jsem nadhodil na Twitteru, na první pohled se to může zdát jako over-engineered řešení – a dostalo se mi několika zajímavých reakcí.

Aleš Roubíček navrhuje udělat pro každou metodu, která potřebuje aktuální čas, další overload, který má další parametr typu DateTime. To je zajímavé řešení, ale nelíbí se mi, že si zaprasíme veřejné API oné třídy. Ano, metoda s parametrem navíc by mohla být internal a mohli bychom použít InternalsVisibleTo, ale…;-)
Dobrý protiargument proti Alešově řešení nadnesl Dan Kolman – co když nějaká jiná metoda volaná během testu používá onu metodu bez parametru (a tedy používající DateTime.UtcNow) ? Pak jsme v koncích…

S další reakcí přišel Filip Kinský, který navrhuje toto řešení. To je docela fajn, protože nevoláme napřímo standardní DateTime.Now, jejíž hodnotu nemáme možnost změnit. Nyní můžeme změnit delegáta, který obstarává získání aktuálního času. Problém je ale v tom, že tato závislost není povinná (nikdo nás nenutí nastavit property CurrentDateTime) a třída tak v deklaraci konstruktoru neinformuje o této závislosti. A to je z mého hlediska problém, protože na nepovinnou závislost nevěřím – toto sousloví vnímám jako oxymóron

Vzásadě jsme se ale shodli, že odstínit přístup k aktuálnímu času (coby globálnímu stavu), je z hlediska testovatelnosti dobré.

Shrnutí na závěr je takové, že byste se měli ve svém kódu vyvarovat použití globálního stavu napřímo – z hlediska testovatelnosti (která jde ruku v ruce s dobrým návrhem obecně) je vhodné mít přístup ke globálnímu stavu odstíněn, abychom ho mohli kdykoliv nahradit.
Ještě bych dodal, že každá třída by měla mít všechny své závislosti dostat přes parametry konstruktoru (volání konstruktoru se nemůžeme vyhnout). Zároveň ale pamatujte na Law of Demeter a předávejte do třídy je ty závislosti, které třída přímo potřebuje.

Vymezení pojmů

Většina pojmů, které používám, vychází z DDD. Pokud se podíváme na aplikace třívrstvýma očima, je v tomto článku řeč především o prostřední vrstvě (business, doménové, logické, …) a možná částečně o nejnižší (datové) vrstvě (pokud do ní chceme zahrnout DAL). Není vůbec řeč o prezentační vrstvě (MVC, MVP, MTV, MVVM).

Application Service

Prezentační vrstva by měla komunikovat s prostřední vrstvou (tj. vlastní aplikací) přes Application Service (tak o ní mluví Eric Evans), což je jedno nebo více rozhraní a související DTOs (tedy něco snadno vystavitelného třeba jako WebService). Každá metoda tohoto rozhraní představuje jeden use-case a tedy logickou transakci. Implementace této vrstvy vypadá tak, že se pouze volá Domain Model (o tom více níže).
Martin Fowler o této vrstvě mluví jako o Service Layer (rozkliknout – obsahuje důležitý obrázek!) a myslím, že s ním nejsem v rozporu.
Na tohle téma je můj názor ustálený, ale rád si přečtu i jiné pohledy na věc.

Domain Model

Vlastní jádro aplikace je ukryto v Domain Modelu, což je vrstva, která by měla obsahovat veškerou logiku naší aplikace. Jak by měla ale taková vrstva vypadat?
Klasický DDD přístup je ten, že by to měl být přirozený OO obraz naší aplikace, tj. měly by to být třídy, které nesou nejen data, ale obsahují také chování (doménové metody). Zde vzniká problém, že u některých metod může být složité rozhodnout, ve které třídě by měly být (třeba protože pracují s více entitami). Proto se zavádí pojem Domain Service, což je interface/třída, která obsahuje právě tyto těžko umistitelné metody. Zde se nabízí otázka, proč bychom měli tyto doménové servisy abstrahovat pomocí interfejsů, když jsou ve stejném modulu, který obsahuje doménové objekty, které také neabstrahují své metody. Jediná rozumná odpověď, která mě napadá, je testování.

Na výše popsaném klasickém přístupu se mi nelíbí to, že některé metody jsou přímo v entitách a některé v doménových servisách. Zde máme vzásadě dvě (extrémní) řešení:
1) Budeme se snažit namodelovat naší doménovou vrstvu takovým způsobem, abychom doménové servisy jednoduše nepotřebovali. To může vyústit v to, že budeme mít entity, které budou popisovat nějaký proces (což může být ok), v horším případě ve vytváření umělých entit (de facto tedy doménových servis).
2) Veškerou doménovou logiku přesuneme do doménových servis a z entit nám tak vzniknou jen schránky na data a budeme tak mít anemický doménový model. Jak moc tento název zní nezdravě a mluví se o něm jako o anti-patternu, tak i tento postup může být pro specifickou doménu to nejlepší řešení. Doménové servisy jsou pak vlastně kontejnery na transakční skripty. Sice se tím zřekneme jedné z hlavní myšlenek OOP (že data a chování by měly být u sebe) a de facto se tím vrátíme k procedurálnímu programování, ale nemyslím si, že je to vyloženě špatně.

Co vy na to? Považujete anemický model za zhůvěřilost nehodnou života v 21. století?

Persistence

Schopnost ukládat a načítat data z nějakého úložiště se abstrahuje do Repository a slouží tedy k abstrakci úložiště od domény. Co by měla taková repozitory obsahovat? Asi by tu měly být nějaké metody pro načtení a uložení objektu…ale jaké konkrétně? Základní CRUD operace jsou asi samozřejmostí, ale co složitější dotazy? Upřednostňujete Specification, Query Object nebo explicitní metody pro každý dotaz? Co je váš favorit?

A co dotazy reportovacího charakteru? Já bych je dal do read-only QueryRepository – z hlediska CQRS to není nutné, ale IMHO je to velmi vhodné.

A jak by měly vypadat implementace běžných repositories? Pokud pracujeme proti relační databázi, tak je myslím nabíledni použít nějaký DAO, typicky objektově-relační mapper.
Protože repositories vytváří doménové objekty, je třeba vyřešit ještě jednu důležitou věc – tyto objekty mohou mít nějaké závislosti a ty je třeba do těchto objektů nějak dostat. Měla by tedy repository injectovat závislosti do doménových objektů? Nebo by měla tento úkol delegovat na nějakou Factory? Pak ale potřebujeme od DAO, aby nám umožnila řídit vytváření instaní objektů, což nemusí být samozřejmostí…
Co myslíte, kdo by měl zajišťovat injektování závislostí do doménových objektů? A jaké závislosti vůbec mohou v doménových objektech být?

Kapitola sama pro sebe jsou transakce a Unit Of Work. Jak jsem psal v úvodu, tak do jedné transakce bych strčil celou metodu aplikační servisy – pak není problém si naijectovat transakční objekt nebo UnitOfWork do implementace repository.

Shrnutí

V článku jsem se snažil popsat svůj pohled na návrh architektury aplikace, přičemž jsem velmi ovlivněn DDD. Při uvádění těchto principů do praxe jsem přirozeně narazil na několik záseků – ať už kvůli mé neznalosti nebo nepochopení, tak kvůli nejednoznačnosti (existuje více správných cest, každá vhodná v jiné situaci). V textu jsem explicitně vypíchnul jen pár otázek, ale budu rád, když mě opravíte/poučíte i v něčem jiném

Closure si tedy můžeme představit jako delegáty, které si sahají někam mimo své tělo, čímž do delegáta vnáší kontext prostředí, ve kterém byly vytvořeny.

Anonymní metody

Do verze C# 2.0 jsme sice měli k dispozici delegáty, ale mohli jsme do nich přiřazovat jen celé metody.

public class Test
{
  public delegate string TestDelegate(int i); // deklarace typu

  static string Test(int i)
  {
    return i.ToString();
  }

  public static void Main()
  {
    TestDelegate d = new TestDelegate(Test);
    // nebo TestDelegate d = Test;
    Console.WriteLine(d(1));
  }
}

Od C# 2.0 byly ale zavedeny anonymní metody, což je konstrukt, který nám umožní vytvořit metodu uvnitř jiné metody.

public class Test
{
  public delegate string TestDelegate(int i); // deklarace typu
  // to same jako Func<int, string>

  public static void Main()
  {
    TestDelegate d = delegate(int i) { return i.ToString(); };
    Console.WriteLine(d(1));
  }
}

No a konečně od C# 3.0 máme k dispozici lambda funkce:

public class Test
{
  public static void Main()
  {
    Func<int, string> d = i => { return i.ToString(); };
    Console.WriteLine(d(1));
  }
}

Pokud máme v těle anonymní metody jen jeden příkaz, můžeme si odpustit i složené závorky:

public class Test
{
  public static void Main()
  {
    Func<int, string> d = i => i.ToString();
    Console.WriteLine(d(1));
  }
}

A nyní se podívejme Reflectorem, co nám leze z kompilátoru:

public class Test
{
  [CompilerGenerated]
  private static string <Main>b__0(int i)
  {
    return i.ToString();
  }

  public static void Main()
  {
    Func<int, string> d = new Func<int, string>(Test.<Main>b__0));
    Console.WriteLine(d(1));
  }
}

Vidíme, že kompilátor udělal prakticky to samé, co jsme museli dělat ručně do příchodu C#2.0 – tedy vyextrahoval tělo do nové metody.
Jen jsem z originálního kódu odstranil cachování, které zajišťuje, aby se při vícenásobném volání nemusel neustále vytvářet stejný objekt Func<int, string>.

Closures

A teď zpátky ke closures, tedy delegátům, které si sahají mimo své tělo. Všimněte si, že to výše uvedené příklady nedělaly – pracovaly jen se svými parametry. Další příklad ale closure již obsahuje:

public class Test
{
  public static void Main()
  {
    string prefix = GetPrefix();
    Func<int, string> d = i => prefix + i.ToString();
    Console.WriteLine(d(1));
  }
}

Nyní máme proměnnou prefix, na kterou si saháme z těla delegáta do nadřazené metody.
Důležité je si uvědomit, že s delegátem d můžeme dělat cokoliv, tj. třeba ho vrátit jako návratovou hodnotu nebo ho někam uložit – tedy životnost delegáta může být delší než život lokální proměnné metody. Jak se s tímto vypořádal kompilátor?

public class Test
{
  [CompilerGenerated]
  private sealed class <>c__DisplayClass1
  {
    public string prefix;
    public string <Main>b__0(int i)
    {
       return (this.prefix + i.ToString());
    }
  }

  public static void Main()
  {
    <>c__DisplayClass1 CS$<>8__locals2 = new <>c__DisplayClass1();
    CS$<>8__locals2.prefix = GetPrefix();
    Func<int, string> d = new Func<int, string>(CS$<>8__locals2.<Main>b__0);
    Console.WriteLine(d(1));
  }
}

Proměnná prefix nemůže být v tomto případě nadále lokální proměnnou (umístěnou na stacku), ale je třeba ji umístit do pomocné, automaticky vygenerované třídy. Spolu s lokální proměnnou prefix se do ní přesunula i anonymní metoda. Instance této třídy je vytvořena při každém volání metody Main.
Automaticky vygenerovaná třída <>c__DisplayClass1 je tedy jakýmsi zhmotněním pojmu closure (uzávěr)

Vhnízděné closures

Začněme složitejším příkladem – vytvoříme pole delegátů, kde každý delegát vrátí jedno číslo:

public class Test
{
  public static void Main()
  {
    var delegates = new Func<string>[5];
    for(int i = 0; i < delegates.Length; i++)
    {
      delegates[i] = () => i.ToString();
    }
    foreach(var d in delegates)
    {
      Console.WriteLine(d());
    }
  }
}

Tento kód nefunguje tak, jak by se mohlo na první pohled zdát. Nevypíšou se totiž čísla 0 až 4, ale vypíše se pěkrát číslo 5. Lokální proměnná i je totiž takto deklarována se scopem na celé metodě. A jak jsme si ukázali, delegáti mají živou vazbu na lokální proměnné, takže v okamžiku, kdy je voláme z foreach cyklu, pracují s aktuální hodnotou proměnné i.
Pokud chceme, aby kód pracoval podle našich představ (tj. vypsal čísla 0 až 4), musíme zajistit, aby si tělo delegátu sahalo na proměnnou, která se nebude dále měnit:

public class Test
{
  public static void Main()
  {
    var delegates = new Func<string>[5];
    for(int i = 0; i < delegates.Length; i++)
    {
      var scopedI = i;
      delegates[i] = () => scopedI.ToString();
    }
    foreach(var d in delegates)
    {
      Console.WriteLine(d());
    }
  }
}

Zavedli jsme pomocnou proměnnou scopedI, která již nemá scope na celé metodě, ale je deklarována na úrovni bloku. Můžeme si to tedy představit tak, že proměnná scopedI vznikne znovu při každém vstupu do bloku (v našem případě do těla for cyklu). A co na to kompilátor?

public class Test
{
  [CompilerGenerated]
  private sealed class <>c__DisplayClass1
  {
    public int scopedI;
    public string <Main>b__0()
    {
        return this.scopedI.ToString();
    }
  }
  public static void Main()
  {
    var delegates = new Func<string>[5];
    for (int i = 0; i < delegates.Length; i++)
    {
        <>c__DisplayClass1 CS$<>8__locals2 = new <>c__DisplayClass1();
        CS$<>8__locals2.scopedI = i;
        delegates[i] = new Func<string>(CS$<>8__locals2.<Main>b__0);
    }
    foreach (var d in delegates)
    {
        Console.WriteLine(d());
    }
  }
}

Jak vidno, kompilátor správně detekoval, že je třeba vytvořit instanci pomocné třídy (držící hodnotu lokální proměnné) v každé iteraci cyklu. Delegát opět ukazuje na metodu v nově vytvořené instanci.

Předchozí příklady byly příprava pro la grande finale – vhnízděné closures. Nejzajímavější kód totiž kompilátor vygeneruje, když máme více vnořených bloků:

public class Test
{
  public static void Main()
  {
    string prefix = GetPrefix();
    var delegates = new Func<string>[5];
    for(int i = 0; i < delegates.Length; i++)
    {
      var scopedI = i;
      delegates[i] = () => prefix + scopedI.ToString();
    }
    foreach(var d in delegates)
    {
      Console.WriteLine(d());
    }
  }
}

Opět se zaměřme hlavně na tělo delegáta. To si nyní nesahá na vnitřní closure, obhospodařující lokální proměnnou scopedI, ale sahá i o blok výše – na proměnnou prefix.

public class Test
{
  [CompilerGenerated]
  private sealed class <>c__DisplayClass1
  {
    public string prefix;
  }

  [CompilerGenerated]
  private sealed class <>c__DisplayClass3
  {
    public Test.<>c__DisplayClass1 CS$<>8__locals2;
    public int scopedI;
    public string <Main>b__0()
    {
        return (this.CS$<>8__locals2.prefix + this.scopedI.ToString());
    }
  }

  public static void Main()
  {
    <>c__DisplayClass1 CS$<>8__locals2 = new <>c__DisplayClass1();
    CS$<>8__locals2.prefix = GetPrefix();
    var delegates = new Func<string>[5];
    for (int i = 0; i < delegates.Length; i++)
    {
      <>c__DisplayClass3 CS$<>8__locals4 = new <>c__DisplayClass3();
      CS$<>8__locals4.CS$<>8__locals2 = CS$<>8__locals2;
      CS$<>8__locals4.scopedI = i;
      delegates[i] = new Func<string>(CS$<>8__locals4.<Main>b__0);
    }
    foreach (Func<string> d in delegates)
    {
      Console.WriteLine(d());
    }
  }
}

Jak vidno, kompilátor se s nastalou situací hrdinně vypořádal. Vytvořil si pomocnou třídu, která obsahuje lokální proměnné deklarované na úrovni celé metody. Stejně jako v předchozích příkladech si vytvořil další pomocnou třídu, která se stará o proměnné deklarované v těle cyklu. A to nejdůležitější – tato třída obsahuje odkaz na první jmenovanou (viz přiřazení na druhém řádku v cyklu).

Shrnutí

Kompilátor C# od verze 2.0 nabízí možnost sahat si z anonymních metod (resp. lambda funkcí) mimo jejich tělo – podporuje tzv. closures. Ty jsou implementovány celkem přímočaře – každý uzávěr je reprezentovaný pomocnou třídou a při každém vstupu do bloku je vytvořena instance odpovídající pomocné třídy (reprezentující closure).
Je to vlastnost, bez které bychom se jistě dokázali v jazyce obejít, ale mít možnost zanést do delegáta kontext prostředí, ve kterém vznikl, je velmi užitečný a překvapivě častý. Např. i tento, na první pohled primitivní kód, využívá closures!

public class Test
{
  public static void Main()
  {
    var toShow = int.Parse(Console.ReadLine());
    foreach(var number in GetArray().Where(i => i == toShow))
    {
      Console.WriteLine(number);
    }
  }
}

P.S.: Na toto téma jsem již blogoval, ale tentokrát jsem to chtěl vzít trošku podrobněji.