michal kohut's blog

LINQ to Entities a porovnanie IS NULL

michal.kohut — Mon, 30 Jan 2012 20:09:00 GMT

Pred nedávnom som narazil na vcelku čudné správanie sa LINQ To Entites pri dopytoch obsahujúcich podmienku testujúcu stĺpec na null.

Majme dva LINQ výrazy, ktoré vyzerajú na prvý pohľad rovnako:

var query1 = from orderItem in context.OrderItems
             where orderItem.Description == null 
             select orderItem;

string description = null;
var query2 = from orderItem in context.OrderItems
             where orderItem.Description == description
             select orderItem;

Očakával by som, že preložené SQL dotazy budú taktiež rovnaké. To však ani zďaleka.

Kým prvý vyzerá takto:

SELECT [Extent1].[Id] AS [Id], 
       [Extent1].[Item] AS [Item], 
       [Extent1].[UnitPrice] AS [UnitPrice], 
       [Extent1].[OrderId] AS [OrderId], 
       [Extent1].[Description] AS [Description]
FROM   [dbo].[OrderItems] AS [Extent1]
WHERE  [Extent1].[Description] IS NULL;

druhý výraz je odlišný:

SELECT [Extent1].[Id] AS [Id],
       [Extent1].[Item] AS [Item],
       [Extent1].[UnitPrice] AS [UnitPrice],
       [Extent1].[OrderId] AS [OrderId],
       [Extent1].[Description] AS [Description]
FROM   [dbo].[OrderItems] AS [Extent1]
WHERE  [Extent1].[Description] = @p__linq__0;

Čo je dôležitejšie, výsledky týchto dotazov sú úplne rozdielne. Kým prvý vráti všetky záznamy so stĺpcom Description rovným null (žiadaný výsledok), druhý dotaz nevráti žiadne záznamy. Ak by išlo o LINQ To SQL, existuje tu jednoduchý workaround, ktorý spočíva v použití metódy object.Equals (tá v tomto prípade zabezpečí, že ak je parameter rovný null, podmienka v SQL bude IS NULL, v opačnom prípade pôjde o klasické porovnanie):

var query = from orderItem in context.OrderItems
            where object.Equals(orderItem.Description, description)
            select orderItem;

Bohužial tento spôsob nefunguje pre LINQ To Entities.

Workarounds

Existuje však niekoľko iných možností ako docieliť požadované správanie:

Možnosť 1

Nejde práve o najestetickejšie riešenie, ale výsledkom je vždy správny (a jednoduchý) SQL dotaz, ktorý je posielaný do databázy:

var query = description == null
            	? (from orderItem in context.OrderItems
                where orderItem.Description == null
                select orderItem)
                : (from orderItem in context.OrderItems
                where orderItem.Description == description
                select orderItem);

Možnosť 2

Inou možnosťou je výraz:

var query = from orderItem in context.OrderItems
            where (description == null) ? orderItem.Description == null : orderItem.Description == description
            select orderItem;

Priemetnutím do SQL ale dostávame poriadnu divočinu (i keď ide o funkčné riešenie):

SELECT [Extent1].[Id] AS [Id], 
       [Extent1].[Item] AS [Item], 
       [Extent1].[UnitPrice] AS [UnitPrice], 
       [Extent1].[OrderId] AS [OrderId], 
       [Extent1].[Description] AS [Description]
FROM   [dbo].[OrderItems] AS [Extent1]
WHERE  (CASE 
	WHEN (@p__linq__0 IS NULL) THEN CASE 
	WHEN ([Extent1].[Description] IS NULL) THEN cast(1 as bit) ELSE cast(0 as bit) 
	END 
	WHEN ([Extent1].[Description] = @p__linq__1) THEN cast(1 as bit) 
	WHEN ([Extent1].[Description] <> @p__linq__1) THEN cast(0 as bit) 
	END) = 1;

Možnosť 3

Dalšou alternatívou je výraz:

var query = from orderItem in context.OrderItems
            where
            	((description == null && orderItem.Description == null) ||
                 orderItem.Description == description)
            select orderItem;

V tomto prípade je vygenerovaný dotaz o niečo jednoduchší ako predošlá verzia:

SELECT [Extent1].[Id] AS [Id],
       [Extent1].[Item] AS [Item],
       [Extent1].[UnitPrice] AS [UnitPrice],
       [Extent1].[OrderId] AS [OrderId],
       [Extent1].[Description] AS [Description]
FROM   [dbo].[OrderItems] AS [Extent1]
WHERE  ((@p__linq__0 IS NULL)
	AND ([Extent1].[Description] IS NULL))
	OR ([Extent1].[Description] = @p__linq__1);

Existujú samozrejme i ďalšie spôsoby ako obísť tento nepríjemný "bug" v LINQ To Entities. A kto vie, možno sa niekedy dočkáme i oficiálnej opravy:)

Prečo mi Visual Studio štartuje tak dlho ?

michal.kohut — Sun, 13 Nov 2011 14:05:00 GMT

Ako nadšený fanúšik Visual Studia si neodpustím doň nainštalovať a vyskúšať takmer každé rozšírenie (po našom extension), ktoré sa mi zdá byť aspoň trochu použiteľné. Výsledkom však v konečnom dôsledku je, že štart prostredia potom trvá niekoľko násobne dlhšie. Otázka je, čo teraz s tým? Mám vypnúť všetky rozšírenia? Nebude stačiť, ak nájdem len tie, ktorých štart trvá najdlhšie? Ale ako to zistiť?

Visual Studio 2010 (uvedený spôsob by mal fungovať s menšími obmenami i pre staršie verzie) je možné spustiť z príkazového riadku s prepínačom /Log:

Tento prepínač zabezpečí, že VS bude celú svoju aktivitu (vrátane načítavania jednotlivých rozšírení) zaznamenávať do súboru. Ak nie je explicitne uvedený výstupný súbor, záznamy budú implicitne uložené v súbore:

%APPDATA%\Microsoft\VisualStudio\10.0\ActivityLog.xml

V tomto adresári sa nachádza i príslušný XSL súbor ActivityLog.xsl, ktorý zabezpečuje omnoho čitateľnejšie zobrazenie XML súboru v prehliadači:

Pri znalosti jazyka XSL je možné súbor ActivityLog.xsl samozrejme ľubovoľne prispôsobiť a upraviť tak zobrazenie ActivityLog.xml v prehliadači. Jedno také veľmi šikovné hotové prispôsobenie sa mi podarilo nájsť.

Táto vylepšená verzia:

zobrazuje dobu načítania jednotlivých balíkov,
zobrazuje vizuálny indikátor každú 1 sekundu (konfigurovateľný parameter),
zobrazí riadok "End package load" červenou farbou v prípade, že čas načítavania balíka prekročí 500ms (konfigurovateľný threshold),
zobrazí červenou každý riadok, ktorého trvanie prekročí konfigurovateľnú hodnotu (implicitne 500ms).

Úvodná tabuľka Summary ostala v podstate nezmenená, obsahuje sumárnu informáciu o celkovom počte správ rozdelených podľa jednotlivých úrovní:

Novinkou je tabuľka Hot Spots, ktorá zobrazuje celkový prehľad všetkých "bodov", v ktorých sa Visual Studio zdržalo dlhšie ako bol prednastavený časový limit - vyššie spomínaný threshold. Takto je v podstate okamžite možné lokalizovať problémové miesta štartu VS.

Použitie tohto modifikovaného XSL súboru je veľmi jednoduché. Jediné, čo treba urobiť je skopírovať ho do adresára, kde sa nachádza príslušný log súbor, v tomto prípade ActivityLog.xml. Po otvorení XML súboru v internetovom prehliadači bude XSL súbor ActivityLog.xsl automaticky použitý pre transformáciu a renderovanie XML súboru.

A samozrejme linka na upravený ActivityLog.xml, ktorého autorom je Lars Corneliussen.

Entity Framework a mazanie objektov pri odloženom vyhodnocovaní

michal.kohut — Mon, 03 Oct 2011 17:58:00 GMT

Jednou z veľmi užitočných vlastností Entity Framework-u je bezpochyby odložené vyhodnocovanie dotazov. Inými slovami povedané, objekty sú získavané z databázy len ak je to skutočne nevyhnutné - ak s nimi chceme voľačo robiť. Odložené vyhodnocovanie alebo tiež Lazy Loading má svoje výhody ako i nevýhody. Na jednej strane dokáže zvýšiť produktivitu pri menšom množstve kódu, na strane druhej programátor stráca kontrolu nad tým, kedy dochádza k prístupu do databázy.

Nepozornosť (alebo povrchná znalosť:)) pri práci s odloženým vyhodnocovaním dokáže niekedy pripraviť naozaj nemilé prekvapenia. Pred nedávnom som takto narazil na jednu záludnosť pri realizácii jednoduchej operácie mazanie entít. Majme dve triedy reprezentujúce doménové modely:

public class User
{
    public int Id { get; set; }
 
    public string Name { get; set; }
 
    public virtual Address Address { get; set; }
}
 
public class Address
{
    public int Id { get; set; }
 
    public string Street { get; set; }
 
    public string City { get; set; }
 
    public virtual ICollection<User> Users { get; set; }
}

Pri prístupe Code First v EF 4.1 obsahuje vygenerovaný databazový model dve tabuľky Users a Addresses, pričom tabuľka Users obsahuje FK (nullable foreign key) na tabuľku Address:

Mapovanie DB modelov, prístup k nim i k ich súvisiacim entitám funguje bez problémov, zväčša ide o jednoduchý a čitateľný kód. Ťažkosti môžu nastať, ak chceme nejakú adresu zmazať. Fragment kódu pre zmazanie adresy s Id == 1, by mohol vyzerať nasledovne:

using (var context = new TestContext())
{
    var address = context.Addresses.Find(1);
    context.Addresses.Remove(address);
    context.SaveChanges();
}

Očakávané správanie je zmazanie danej adresy z databázy a nastavenie príslušných cudzích kľúčov Address_Id v tabuľke Users na NULL (pre tých používateľov, ktorí mali danú adresu priradenú). V skutočnosti však pri volaní metódy context.SaveChanges() obdržíme výnimku typu DbUpdateException:

Vnútorná výnimka obsahuje správu:

The DELETE statement conflicted with the REFERENCE constraint Address_Users. The conflict occurred in database DbName, table dbo.Users, column 'Address_Id'.The statement has been terminated.

Problém, ktorý nastal, súvisí práve s odloženým vyhodnocovaním v Entity Framework-u. Objekt typu Address má navigačnú vlastnosť, ktorá reprezentuje kolekciu všetkých používateľov, ktorí majú pridelenú danú adresu. Pri mazaní adresy je nevyhnutné, aby relevantné cudzie kľúče používateľov (tie ktoré odkazujúce na túto adresu) boli "vynulované". Na to je ale potrebné všetkých týchto používateľov explicitne načítať. I keď fragment kódu pre mazanie adresy, ktorý je uvedený vyššie, pôsobí jednoducho a intuitívne, Entity Framework si s ním neporadí.

Riešenie spočíva vo využití explicitného načítania tzv. related properties, v tomto prípade kolekcie súvisiacich používateľov s danou adresou:

using (var context = new TestContext())
{
    var address = context.Addresses.Find(1);
    context.Entry(address).Collection(c => c.Users).Load();
    context.Addresses.Remove(address);
    context.SaveChanges();    
}

V tomto prípade by ma naozaj potešilo, keby fungoval prvý zápis - čiže verzia bez "čudného" riadku, obsahujúceho volanie metódy Load(). Kto vie aké vylepšenia prinesú ďalšie verzie EF...

Konfigurácia knižnice Automapper s Unity IOC

michal.kohut — Sat, 10 Sep 2011 15:06:00 GMT

S mapovaním nejakého objektu na iný objekt sa stretol hádam každý programátor. Ide o zvlášť "populárnu" činnosť v projektoch využívajúcich architektúry ako MVC alebo MVVM. Fragmenty kódu, kde sú mapované vlastnosti modelu na vlastnosti príslušného viewmodelu a naopak vedia poriadne pokaziť estetický dojem z kódu. Ich písanie je navyše nudné, otravné a čo je najhoršie - opakujúce sa.

AutoMapper

Našťastie existujú nástroje, ktoré toto mapovanie robia za nás. Jedným z takých je knižnica AutoMapper, ktorej autorom je Jimmy Bogard (spoluautor kníh ASP.NET MVC in Action a ASP.NET MVC 2 in Action). Jej aktuálnu verziu je možné do projektu nainštalovať prostredníctvom PM konzoly príkazom:

PM> Install-Package AutoMapper

Väčšina návodov na použitie AutoMapper-a používa statickú triedu Mapper, obvykle v dvoch základných krokoch:

definícia mapovania:

Mapper.CreateMap<SourceType, TargetType>();

samotné mapovanie:

var target = Mapper.Map<SourceType, TargetType>(source);

Problém spojený so statickými triedami a metódami však nastane v prípade potreby jednotkového testovania zdrojového kódu a jeho izolácie. Statické triedy a statické metódy sú elementami procedurálného kódu a ich tzv. mockovanie v prípade potreby izolácie nejakej testovanej komponenty je nemožné. Trieda Mapper z knižnice AutoMapper je však len akýmsi wrapper-om pre dve triedy, ktoré poskytujú skutočnú funkcionalitu - Configuration a MappingEngine.

AutoMapper a Unity

Cieľom je teda integrovať AutoMapper do projektu, v ktorom je použitý niektorý z DI (Dependency Injection) kontajnerov. V tomto konkrétnom prípade pôjde o DI kontajner Unity od spoločnosti MIcrosoft. Princíp by mal ale bude fungovať pre ľubovoľný iný DI kontajner.

Základný resolving pre kľúčové typy knižnice AutoMapper-a by mal vyzerať nasledovne:

žiadosť pre rozhranie IConfiguration vráti typ Configuration,
žiadosť pre rozhranie IConfigurationProvider vráti typ Configuration a
žiadosť pre rozhranie IMappingEngine vráti typ MappingEngine.

Konkrétna konfigurácia kontajnera Unity by mala byť jasná, za zmienku možno stojí spôsob registrovania samotného typu Configuration. Inštancia triedy Configuration je vytváraná pomocou factory metódy, ktorá volá priamo konštruktor triedy Configuration. Parameter ContainerControlledLifetimeManager určuje životnosť inštancie triedy Configuration - v tomto prípade to znamená Singleton, nakoľko chceme mať v celej aplikácii jedinú inštanciu tejto triedy, ktorá bude obsahovať konfiguráciu pre všetky mapovania.


    var container = new UnityContainer();
    container.RegisterType<Configuration>(new ContainerControlledLifetimeManager(),
        new InjectionFactory((c) => new Configuration(new TypeMapFactory(), MapperRegistry.AllMappers())));
 
    container.RegisterType<IConfiguration, Configuration>();
    container.RegisterType<IConfigurationProvider, Configuration>();
    container.RegisterType<IMappingEngine, MappingEngine>();

Použitie objektu typu IMappingEngine pre realizáciu samotného mapovania:

    var mappingEngine = container.Resolve<IMappingEngine>();
    var target = mappingEngine.Map<SourceType, TargetType>(source);

Registrácia mapovania

Pravdepodobne nie je žiadúce, aby sme mali všetky konkrétne mapovania definované niekde na jednom mieste a radšej uprednostníme trochu modulárnejšie riešenie. Keďže máme k dispozícii DI kontajner, pôjde to celkom ľahko. Najprv vytvoríme rozhranie, ktoré bude definovať konkrétne mapovanie typov. Pre ilustráciu uvediem i príklad implementácie tohto rozhrania:

    public interface IMappingRegistration
    {
        void RegisterMapping(IConfiguration configuration);
    }

    public class SampleMappingRegistration : IMappingRegistration
    {
        public void RegisterMapping(IConfiguration configuration)
        {
            configuration.CreateMap<SourceType, TargetType>();
        }
    }

Takto vytvorené mapovanie je následne potrebné registrovať v konfigurácii pre Unity kontajner:

    container.RegisterType<IMappingRegistration, SampleMappingRegistration>();
    container.RegisterType<IMappingRegistration, AnotherMappingRegistration>();

No a na záver už len ostáva niekde pri štarte aplikácie (Bootstrap) všetky tieto mapovania registrovať:

    var config = container.Resolve<IConfiguration>();
    var mappings = container.ResolveAll<IMappingRegistration>();
    foreach (var mappingRegistration in mappings)
        mappingRegistration.RegisterMapping(config);

Výsledkom je vlastne distribúcia definícií konkrétnych mapovaní do viacerých tried (implementujúcich rozhranie IMappingRegistration). Navyše celý tento spôsob integrovania knižnice AutoMapper do projektu nevytvára žiadne väzby na statickú triedu Mapper, náš kód ostáva testovateľný, čistý a loosely coupled.

Ako skonvertovať fragment kódu do formátu HTML vo VS 2010

michal.kohut — Wed, 24 Aug 2011 17:18:00 GMT

Alebo funkcia HTML Copy z Productivity Power Tools

Keď som písal svoj prvý blog, čo vlastne nebolo tak dávno, zasekol som sa na chvíľu pri probléme ako čo najjednoduchšie a najrýchlejšie dostanem kód z VS do HTML. Cieľom bolo samozrejme, aby kód vyzeral presne rovnako. Musím sa priznať, že som pôvodne očakával nejaké jednoduché klikacie menu pre formátovanie textu, ktoré bude dostupné pri tvorení nového článku v Blog Management-e. Fakt, že musím písať text v HTML ma teda trošku prekvapil. Na druhej strane ale treba priznať, že priame použitie jazyka HTML ponúka široké možnosti formátovania textu a v podstate i celého článku.

Takže som začal hľadať vhodný nástroj/spôsob ako skonvertovať zdrojový kód v C# do jazyka HTML. Vyskúšal som online tool manoli, addiny CopySourceAsHtml, Code4Blog.

Neviem, či bol problém vo mne, ale akosi ani jednému z nich som neprišiel na chuť. Až potom som sa niekde dočítal, že rošírenie pre VS 2010 Productivity Power Tools obsahuje funkciu nazvanú HTML Copy. Funguje to presne tak ako som chcel, aby to fungovalo. Jednoducho a hlavne rýchlo. Navyše keďže som už toto rozšírenie mal nainštalované, nepotreboval som inštalovať nič naviac.

Ako na to

Fragment kódu, ktorý má byť konvertovaný stačí jednoducho označiť a dať kopírovať (príkaz Copy z kontextového menu alebo staré známe CTRL-C).

Obsah clipboardu je teraz potrebné vložiť do editora podporujúceho jazyk HTML (napríklad Windows Live Writer). Keďže však je tento článok o tom, ako celý tento proces zvládnuť vo VS 2010, nepotrebujeme Windows Live Writer ani nič podobné. Vo VS vyberieme z hlavného menu File -> New -> File... -> HTML Page (názov súboru momentálne nie je dôležitý). Kopírovaný text vložíme pomocou príkazu Paste Alternate (dostupný v kontextovom menu alebo v hlavnom menu Edit -> Paste Alternate.

Kód v takejto podobe vyzerá na prvý pohľad dosť odstrašujúco. Po prekonaní prvotného šoku však je možné postupne rozpoznať známe HTML elementy. Nakoniec zistíme, že orientovať sa v tomto kóde nie je až taký problém. Základné nastavenia funkcie HTMLCopy sú dostupné v Tools -> Options -> Productivity Power Tools -> HTML Copy.

A na záver naformátovaný kód v prehliadači:

using System.Linq;
using System.Web.Mvc;
using MvcMusicStore.Models;
 
namespace MvcMusicStore.Controllers
{
    public class StoreController : Controller
    {
        private MusicStoreEntities _storeDb = new MusicStoreEntities();
 
        public ActionResult Index()
        {
            var genres = _storeDb.Genres;
 
            return View(genres);
        }
 
        public ActionResult Browse(string genre)
        {
            var genreModel = _storeDb.Genres.Include("Albums").Single(g => g.Name == genre);
            return View(genreModel);
        }
 
        public ActionResult Details(int id)
        {
            var album = _storeDb.Albums.Find(id);
 
            return View(album);
        }
 
        [ChildActionOnly]
        public ActionResult GenreMenu()
        {
            var genres = _storeDb.Genres.ToList();
 
            return PartialView(genres);
        }
    }
}

Manuálna validácia atribútov z DataAnnotations

michal.kohut — Sun, 21 Aug 2011 09:19:00 GMT

Validácia vstupných dát (prichádzajúcich od používateľa, zo vzdialenej databázy, zo súboru alebo od akéhokoľvek iného zdroja) je nevyhnutnou súčasťou takmer každej aplikácie. Samotný validačný proces možno zjednodušene charakterizovať ako proces zabezpečenia spoľahlivého a bezpečného “bindingu” týchto dát na biznis modely aplikácie. Niekedy môže byť tento proces veľmi zložitý a nepochybne existuje viacero možností ako validačnú logiku navrhnúť.

Framework ASP.NET MVC 3 poskytuje rozšíriteľný a vysoko prispôsobivý mechanizmus ako validovať vstupné dáta pre modely. Od vlastného písania všetkých validačných metód, cez možnosti implementácie rozhrania IValidatableObject, cez tvorbu vlastných ModelBinder-ov obsahujúcich validačné pravidlá, cez použitie elegantných atribútov z DataAnnotations až po písanie vlastných ModelValidatorProvider-ov.

Zámerne som použil výraz elegantné atribúty, pretože ide podľa môjho názoru o veľmi čistý a jednoduchý spôsob ako validovať vstupné dáta (aj keď prináša isté obmedzenia). Pre jeho použitie stačí jednotlivé vlastnosti modelu dekorovať vhodnými atribútmi (Required, StringLength, ...) a následne v akcii triedy controller-a, ktorá prijíma ako vstupný parameter model, je výsledok validácie tohto modelu dostupný vo vlastnosti ModelState.IsValid.

Problém môže nastať ak potrebujeme takýto alebo podobný mechanizmus využiť niekde mimo UI frameworku (akým je ASP.NET MVC), kde dostupný nie je. Stále však máme k dispozícii menný priestor System.ComponentModel.DataAnnotations, a tak riešenie nemusí byť až také náročné. Assembly System.ComponentModel.DataAnnotations obsahuje všetko potrebné k vytvoreniu validačnej logiky presne podľa našich požiadaviek. Ako príklad použijem odľahčenú verziu mierne upraveného návrhového vzoru Command, ktorý sme používali na jednom z predošlých projektov.

Ak píšem o validácii modelu, pod pojmom model mám v nasledujúcom kontexte na mysli triedu Command (a jej potomkov). Začneme definovaním jednoduchého rozhrania ICommand, ktoré deklaruje jedinú metódu pre validáciu, Validate(). Tu sa možno naskytá otázka prečo nevyužiť existujúce rozhranie IValidatableObject. Teoreticky to možné je, akurát mi vadí v tomto prípade zbytočný parameter ValidationContext, ktorý prijíma metóda IValidatableObject.Validate. A navyše názov ICommand lepšie zapadá do našej architektúry.

using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
 
namespace Test.Infrastructure.CommandEngine
{
    public interface ICommand
    {
        IEnumerable<ValidationResult> Validate();
    }
}

Rozhranie je priamo implementované abstraktnou triedou Command, ktorá delí validačný proces na dve časti

AutoValidate - validácia vlastností modelu (property-level)
CustomValidate - validácia samotného modelu (model-level)

Metóda AutoValidate je implementovaná priamo v tejto abstraktnej triede a realizuje validáciu vlastností modelu, pomocou statickej metódy Validator.TryValidateObject.
Metóda CustomValidate je metóda, ktorá môže byť podľa potreby prekrytá už v konkrétnej implementácii Command-u.

using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.Linq;
 
namespace Test.Infrastructure.CommandEngine
{
    public class Command : ICommand
    {
        public IEnumerable<ValidationResult> Validate()
        {
            var results = AutoValidate();
            return results.Union(CustomValidate());
        }
 
        private IEnumerable<ValidationResult> AutoValidate()
        {
            var results = new List<ValidationResult>();
            Validator.TryValidateObject(this, new ValidationContext(this, null, null), results, true);
            return results;
        }
 
        protected virtual IEnumerable<ValidationResult> CustomValidate()
        {
            yield break;
        }
    }
}

Konkrétna implementácia triedy Command by teda mohla vyzerať takto:

using System;
using System.ComponentModel.DataAnnotations;
using Test.Infrastructure.CommandEngine;
 
namespace Test.Infrastructure.Commands
{
    public class UserCreateCommand : Command
    {
        [Required]
        public Guid Id { get; set; }
 
        [Required]
        [StringLength(20)]
        public string Username { get; set; }
 
        [Email]
        public string Email { get; set; }
    }
}

Takže ostáva už len zavolať metódu pre validovanie:

using System;
using Test.Infrastructure.Common;
 
namespace Test.Infrastructure.CommandEngine
{
    public class CommandEngine
    {
        public void Handle(ICommand command)
        {
            ValidateCommand(command);

            //  apply some rules and execute the command 
            //  ... 
        }
 
        private void ValidateCommand(ICommand command)
        {
            var errors = command.Validate();
 
            if (!errors.IsNullOrEmpty())
            {
                throw new ApplicationException();
            }
        }
    }
}

Len pre úplnosť doplním ostatné detaily kódu: Metóda IsNullOrEmpty() je jednoduchou extension metódou pre IEnumerable<T>, atribút [Email] je atribút vytvorený odvodením z triedy RegularExpressionAttribute a v kóde používame vlastnú verziu ValidationExcetion.