Mnohem více se mi líbí uložení metadat někde úplně mimo a vytažení metadat pro danou třídu dynamicky z nějakého metadata-provideru za běhu aplikace. Odkud si metadata onen provider vytáhne je jeho problém – může si je vytáhnout z databáze, konfiguračních souborů nebo klidně z atributů.

ASP.NET MVC

Pokud sledujete vývoj ASP.NET MVC, došlo zde přesně k tomuto posunu od atributů k obecnému metadata-provideru. V prvních verzích ASP.NET MVC se ViewModely odekorovaly pomocí atributů z namespace DataAnnotations a podle toho se vyrenderovaly UI prvky (omezení na max. délku stringu v JavaScriptu apod.).
V posledních verzích došlo k zobecnění a byla zavedena abstraktní třída ModelMetadataProvider, z které můžete podědit a tahat si metadata odkukoliv je libo. Samozřejmě je standardně dodáván DataAnnotationsModelMetadataProvider (to je jméno! ), který čte metadata z DataAnnotations atributů, čímž je zajištěna zpětná kompatibilita.

Díky tomuto obecnému konceptu můžete např. validační pravidla definovat pěkně silně typově pomocí FluentValidation a do ASP.NET MVC je přenést pomocí FluentValidationModelMetadataProvider.

Jak se tedy postavit k použití atributů?

Když už máte nějaké třídy, které jsou odekorovány atributy a nemůžete to změnit, napište alespoň kód pracující s těmito třídami tak, aby se atributy nepoužívaly napřímo, ale zprostředkovaně přes nějakého metadata-providera.

Pokud bych dělal na malé neperspektivní aplikaci, asi bych použití atributů překousl. Ale vždy (vždy!) nějak abstrahujte čtení atributů, tj. nevolejte napřímo GetCustomAttributes. A právě tato abstrakce je de facto onen metadata-provider.

public class HomeController : Controller
{
  public HomeController(ILoginService loginService)
  {
    LoginService = loginService;
  }

  public ILoginService LoginService { get; private set; }

  public ActionResult ShowLogin()
  {
     return PartialView();
  }

  public ActionResult ProcessLogin(Credentials credentials)
  {
     LoginService.Login(credentials);
     // ...not important
  }
}

Pokud se bude přihlašovací dialog zobrazovat na každé stránce (jak bývá zvykem), bude se vždy do tohoto HomeControlleru injectovat nějaká ILoginService – a pokud má konkrétní použitá implementace závislost třeba na IDbConnection (připojení do databáze), tak to už může být problém, protože si třeba zbytečně vytáhneme z connection poolu připojení do databáze, které nám může na zatíženém webu chybět.

Jak z toho ven? V .NETu máme k dispozici třídu Lazy<>, která nám umožní to samé, co popsal David ve svém článku – ke zpřístupnění/vytvoření živé instance ILoginService dojde až tehdy, když si sáhneme na property Value. Implementace bude pak vypadat takto:

public class HomeController : Controller
{
  public HomeController(Lazy<ILoginService> loginService)
  {
    LoginService = loginService;
  }

  public Lazy<ILoginService> LoginService { get; private set; }

  public ActionResult ShowLogin()
  {
     return PartialView();
  }

  public ActionResult ProcessLogin(Credentials credentials)
  {
     LoginService.Value.Login(credentials);
     // ...not important
  }
}

Problem solved, fuck yeah! Nebo ne? Pozorný čtenář začne větřit problém smradlavý kód. V jednom příkazu (první řádek metody ProcessLogin) se nám totiž objevily dvě tečky, což je dobrá indikace toho, že porušujeme Law Of Demeter. Protože je ale Value property BCL objektu, tak bych se z toho hned dogmaticky nehroutil. Ale za bližší prozkoumání tato situace určitě stojí.

Elegantní řešení, kterým se vyhneme použití Lazy a zároveň se zbavíme zbytečného injectování ILoginService, je rozdělit HomeController na dva menší Controllery – to je nakonec správně i podle SRP. Problem solved. Nebo ne? Nevím jak vy, ale já nechci mít v projektu trilión tříd s jednou metodou, takže přemýšlejme dál. A nebo ne – začněme úplně od začátku!

Znovu a lépe

Proč jsme začali vůbec komplikovat ten původní jednoduchý a přímočarý kód? Protože jedna z akčních metod se volá méně častěji a protože vytvoření ILoginService může být náročné. Proč ale do implementace tahat takovéhle předpoklady? Co je HomeControlleru do toho? Tomu musí být jedno, jak je ILoginService implementovaná a jestli je její vytvoření náročné nebo ne – programujeme proti rozhraním!

Jediný, kdo může/musí vědět o konkrétních použitých třídách, jejich vztazích a způsobech použití, je kompoziční root, neboli kontejner. To je místo, kde skládáme z malých kousků výslednou aplikaci.

Takže implementaci HomeControlleru necháme pěknou a čistou, tak jak je v první ukázce kódu. Problém se zbytečným vytvářením těžké implementace ILoginService (nazvěme ji HeavyLoginService) vyřešíme chytrou konfigurací kontejneru:

Vytvoření HomeControlleru nakonfigurujeme tak, že se jako parametr konstruktoru předá jen proxy, která implementuje ILoginService. Při prvním přístupu k této proxy dojde k vytvoření HeavyLoginService a veškerá volání bude proxy delegovat na tuto živou instanci. V kompozičním rootu bychom tedy mohli mít toto:

public class LoginServiceProxy : ILoginService
{
  public LoginServiceProxy(Func<ILoginService> accessor)
  {
     Accessor = accessor;
  }

  private Func<ILoginService> Accessor { get; set; }
  private ILoginService Live { get; set; }

  public LoginResult Login(Creadentials credentials)
  {
    if (Live == null)
    {
       Live = Accessor(); // thread safety?
    }
    return Live.Login(credentials);
  }
}

Předávaná lambda accessor se postará o dodání nějaké živé implementace ILoginService, v našem případě tedy HeavyLoginService.
Jistě uznáte, že psát takovýto kód stále dokolečka dokola pro každý interface (který může mít samozřejmě více metod) je nuda a docela bychom se opakovali. Takže proxy nebudeme psát ručně, ale nějak si je nagenerujeme.

Mohli bychom to dělat třeba pomocí T4 ještě před kompilací, ale já stejně jako můj velký vzor použiji knihovnu Castle DynamicProxy

Nejprve si vytvoříme interceptor, což je de facto implementace všech metod naší proxy, tedy všech metod daného interface:

public class LazyLoadInterceptor<T> : IInterceptor
{
  public LazyLoadInterceptor(Func<T> accessor)
  {
    Accessor = accessor;
  }

  private Func<T> Accessor { get; set; }
  private T Live { get; set; }

  public void Intercept(IInvocation invocation)
  {
    // will be called for all methods
    if (Live == null)
    {
        Live = Accessor();
    }
    invocation.ReturnValue = invocation.Method.Invoke(Live, invocation.Arguments);
  }
}

Je to tedy prakticky to samé, co jsme viděli u ručně psané proxy. Jediný rozdíl je ve způsobu volání živé metody. Toto funguje bezvadně, jen metoda Invoke nepatří k nejrychlejším, tudíž se vyplatí zde použít třeba nacachované generování IL kódu.

Proxy objekt pak vytvoříme takto (v praxi bychom si to asi zabalili to nějaké pěkné Utils metody):

var pg = new ProxyGenerator(); // cache them!
ILoginService proxy = pg.CreateInterfaceProxyWithoutTarget<ILoginService>(
  new LazyLoadInterceptor<ILoginService>(() => new HeavyLoginService()));

Takto získanou proxy uspokojíme závislost HomeControlleru.

Závěr

HomeController zůstal krásně čistý a lazy loading těžké implementace závislosti je krásně skryt za proxy. U mě dobrý.

public class RegistrationService : IRegistrationService
{
  public void RegisterUser(UserToRegister user)
  {
    Repository.Add(user);
    MailingService.SendConfirmation(user);
  }
}

Co když budeme chtít na tuto událost reagovat ještě nějak jinak? Třeba budeme chtít zobrazovat seznam posledních deseti registrovaných uživatelů, stranou si štosovat uživatele, co použili jako registrační mail z GMailu atd.

Kdybychom přidali třeba jen další dvě volání nějakých dalších Services, začal by nám kód pěkně smrdět, protože by třída RegistrationService měla mnoho závislostí. Jak z toho ven?

Nadefinujme si tato dvě velmi jednoduchá rozhraní:

public interface IEventPublisher
{
  void Publish(object e);
}

public interface IEventHandler<TEvent>
{
  void Handle(TEvent e);
}

Rozhraní IEventPublisher bude používat třída, která vyvolává nějakou událost. V našem příkladu bude mít třída RegistrationService závislost na tomto rozhraní, která při použití constructor injection vypadá nějak takto:

public RegistrationService(IRepository repository, IEventPublisher eventPublisher)
{
  // save parameters to the properties or fields
  Repository = repository;
  EventPublisher = eventPublisher;
}

V metodě RegisterUser pak vykonáme jen „primární“ záležitosti (uložení do databáze) a posléze vyvoláme novou událost pomocí volání EventPublisher.Publish(new UserRegistered(user));. Třída UserRegistered reprezentuje událost a je to obyčejná POCO třída.

Každý, kdo chce být informován o události UserRegistered, pak musí implementovat druhé definované rozhraní – IEventHandler<UserRegistered>. Tzn. v metodě Handle pak máme kód, který reaguje na vyvolání události.

public class MailingService : IMailingService, IEventHandler<UserRegistered>
{
  public void Handle(UserRegistered e)
  {
     // send the confirmation e-mail
  }
}

Tím docílíme pěkného oddělení zdroje události od konzumentů události.

Implementace

Samozřejmě musíme nějak zajistit, že po volání Publish dojde k zavolání těch správných event-handlerů. Jednoduchá implementace IEventPublisher založená na kontejneru může vypadat nějak takto:

public class SimpleEventPublisher : IEventPublisher
{
  public void Publish(object e)
  {
    var messageType = e.GetType();
    var eventHandlerType = typeof(IEventHandler<>).MakeGenericType(messageType);
    foreach(var eh in Container.ResolveAll(eventHandlerType)) // we must register all event handlers somewhere
    {
       eh.Handle(e);
    }
  }
}

Tato implementace je velmi naivní, neefektivní a především nejde zkompilovat, protože iterovaná proměnná nebude odpovídajícího generického typu IEventHandler<>. To je ale jen implementační detail, který jde snadno vyřešit pomocí trošky reflexe…

Princip všech implementací IEventPublisher bude ale stejný – odněkud zjistit všechny event-handlery pro daný typ události a pro všechny zavolat metodu Handle. Jednoduché. Ale velmi silné! Jsme totiž schováni za velmi jednoduchým rozhraním a můžeme dělat, co je nám libo.

Např. můžeme každé volání metody Handle obalit try-catchem a tak zajistit, že dojde vždy k zavolání všech event-handlerů.

Nemusíme ani event-handlery volat synchronně – můžeme si událost uložit do nějaké fronty (Message Queue?) a event-handlery volat až později (a zbytečně neblokovat) nebo je třeba zpracovávat na úplně jiném stroji.
Můžeme si event-publisher nakonfigurovat tak, že některé události bude odbavovat synchronně, jiné asynchronně.

Můžeme ale změnit i logiku vyhledávání event-handlerů. Můžeme začít třeba podporovat „dědičnost událostí“, takže IEventHandler<object> by reagoval na všechny události.

A v neposlední řadě můžeme celé toto delegovat na nějaký existující messagingový framework.

Prostě fantazii se meze nekladou!

Použití

Nemá cenu cpát tento koncept do malých nebo jednoduchých aplikací – ideální použití událostí je v komplexnějších aplikacích, kde je hodně závislostí mezi různými částmi aplikace.
Je dokonce možné si nakonfigurovat event-publisher tak, aby se některé vybrané události publikovali i mimo naši aplikaci a informovali o změně stavu nějaké návazné aplikace. Pak přichází ke slovu message bus, což je zjednodušeně řečeno one-way (pub/sub) komunikace mezi aplikacemi.

Zajímavé může být použití konceptu událostí v datové vrstvě. Každý jistě zná triggery z databází – můžete si zaregistrovat funkci, která se při vložení/změně/smazání dat automagicky zavolá. Když ale používáme úložiště, které triggery nepodporuje, nebo máme více úložišť, která mezi sebou neumí na této úrovni spolupracovat, pak potřebujeme posunout triggery o úroveň výše, tj. do našeho kódu.
Události takového typu asi nebudeme chtít vyvolávat ručně, ale budeme to chtít nějak zautomatizovat. Můžeme si třeba napsat aspekt (~wrapper), který zajistí automatické vyvolávání událostí, když se volají metody Add/Remove na Repozitáři.
V praxi to pak může vypadat třeba tak, že ačkoliv máme data uložena v MySql, tak si můžeme napsat event-handler pro událost ProductRemoved, ve kterém invalidujeme položku v Memcached.

Perzistence založená čistě na událostech se nazývá EventSourcing, ale to osobně považuji za extrém, který najde využití u velmi malého počtu projektů.

Takže?

Nadefinovali jsme si dvě rozhraní, která budeme používat v naší aplikaci jako takové. Díky tomu si nazabordelíme projekt referencemi na nějaký specifický framework a můžeme kdykoliv velmi jednoduše změnit implementaci/chování událostí.
Události najdou uplatnění jak v aplikaci jako takové („doméně“), tak na úrovni přístupu k datům. Pokud bychom dotáhli použití událostí do konce, dostali bychom EventSourcing, což je ale dle mého názoru u většiny projektů zbytečné.

Události ale jistě stojí za pozornost minimálně kvůli tomu, že dokáží snížit provázanost jednotlivých částí aplikace.

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.