Webforms mit TDD entwickeln

Diese hier ist schon wieder eine wunderbare Idee aus Jimmy Nilssons Applying Domain-Driven Design and Patterns (das Buch scheint bis zur letzten Seite super Tipps zu liefern ­čśë ) und zwar von Ingemar Lundberg.

Was ist eigentlich die Aufgabe einer Webseite: irgendwelche Controls mit Text zu f├╝llen. Was dieser Text beinhaltet, dass wird von verschiedenen Funktionen entschieden. (Wie er ausgegeben wird, interessiert nicht.) Die Hauptaufgabe also bei der testgetriebenen Entwicklung von Webforms ist, diese Funktionalit├Ąten zu ermitteln und zu implementieren. So bekommt man eine Webanwendung, bei der die Hauptbereiche getestet sind und nur die eigentliche Html-Ausgabe ungetestet bleibt. Au├čerdem wird auf dieser Art sichergestellt, dass die View sonst nichts tut.

Nehmen wir ein einfaches Beispiel: das F├╝llen eines Warenkorbs. Es stehen 3 Produkte zur Auswahl und der K├Ąufer darf in seinen Warenkorb maximal 3 stellen. Um etwas Logik dabei zu haben, wird festgelegt, dass von ein Produkt nur maximal 2-mal gew├Ąhlt werden darf. Wenn diese Bedingung erf├╝llt ist, soll das Produkt nicht mehr ausw├Ąhlbar sein. Gleiches gilt, wenn im Korb bereits 3 Produkte sind, kein Produkt darf mehr ausw├Ąhlbar sein.

Shopping Cart

Das Ausw├Ąhlen eines Produktes passiert z.B. mit einem OnClick-Event auf dem Link. Aus der Sicht der Funktionalit├Ąt ist das nicht wichtig, hauptsache das Event wird ausgel├Âst.

Was tut also ein Modell um eine View zu steuern: nachdem es sichergestellt hat, dass alle Controls leer sind, l├Ądt es die Daten mit irgendeiner Repository (nennen wir sie IDeposit), gibt sie der View und veranlasst diese, die Daten zu rendern. Danach muss es die ├╝bermittelten Daten identifizieren k├Ânnen und, wenn es OK ist, muss es diese mit einer anderen Repository (die nennen wir IAcquisition) abspeichern. Mit diesem “ist OK” wird sichergestellt, dass die obigen Regeln eingehalten wurden, also dass nicht zu viele Produkte bzw. identische Produkte ausgew├Ąhlt wurden. Danach muss die View die Daten wieder rendern.

Mit diesen Informationen k├Ânnen wir bereits das Produkt und die 2 Interfaces definieren, die wir hier als Blackbox betrachten:

namespace WebformMVP.Tests
{
    //Wegen der Bedingung "nicht mehr als zwei vom selben Typ" muss eine Product-Klasse geben. Sonst w├╝rde auch ein string reichen
    public class Product
    {
        public string Name;
        public int Type;
        public Product(string name, int type)
        {
            Name = name;
            Type = type;
        }
    }

    public interface IDeposit
    {
        IList<Product> Load();
    }

    public interface IAcquisition
    {
        void Add(Product product);
    }
}

Jetzt ist endlich Zeit f├╝r den ersten Test. Wie ich schon am Anfang geschrieben habe, eine View muss einfach nur Text darstellen. Um die View simulieren zu k├Ânnen, wird sie von einem Interface abgeleitet, genauso wie die Testklasse, unsere Fakeview. Diese bekommt als Felder strings anstelle von Controls, die allerdings korrekt gef├╝llt werden m├╝ssen. Wir tun so als ob, wir abstrahieren die View auf das Minimum:

namespace WebformMVP.Tests
{
    public interface IShoppingView
    {
        void AddSourceItem(string text, bool available);
    }

    [TestFixture]
    public class Tests : IShoppingView
    {
        string m_sourcePanel;
        string m_shoppingCartPanel;

        [Test]
        public void FillSourcePanel()
        {
            m_model.Fill();
            m_model.Render();

            Assert.That(m_sourcePanel, Is.EqualTo("Product 1 available; Product 2 available; Product 3 available; "));
        }
    }
}

So wird die Anwendung nat├╝rlich nicht mal kompiliert :), dazu brauchen wir noch ein paar Schritte.

Dadurch, dass die Testklasse von diesem Interface ableitet, sind wir in der Lage, die Methoden entsprechend ├╝berschreiben zu k├Ânnen. Dieser Trick nennt sich Implement Interfaces Explicitly. Gleichzeitig lassen wir die Klasse auch von IDeposit ableiten, um auch dessen Methode zu ├╝berschreiben:

namespace WebformMVP.Tests
{
    [TestFixture]
    public class Tests : IShoppingView, IDeposit
    {
        string m_sourcePanel;
        string m_shoppingCart;
        IList<Product> m_sources= new List<Product>{new Product("Product 1", 1), new Product("Product 2", 2), new Product("Product 3", 3)};

        void IShoppingView.AddSourceItem(string text, bool available)
        {
            m_sourcePanel += text + (available ? " available;": string.Empty) + " ";
        }

        IList<Product> IDeposit.Load()
        {
            return m_sources;
        }

        [Test]
        public void FillSourcePanel()
        {
            m_model.Fill();
            m_model.Render();

            Assert.That(m_sourcePanel, Is.EqualTo("Product 1 available; Product 2 available; Product 3 available; "));
        }
    }
}

Es funktioniert immer noch nicht, wir brauchen ja noch ein Modell.

namespace WebformMVP.Tests
{
    public class ShoppingModel
    {
        public void Fill()
        {
            throw new NotImplementedException();
        }
        public void Render()
        {
            throw new NotImplementedException();
        }
    }

    [TestFixture]
    public class Tests : IShoppingView, IDeposit
    {
        ...
        private ShoppingModel m_model;

        //Es muss sichergestellt werden, dass beim Laden der View alle Felder leer sind.
        [SetUp]
        public void Setup()
        {
            m_sourcePanel = string.Empty;
            m_shoppingCart = string.Empty;
            m_model= new ShoppingModel();
        }

        [Test]
        public void FillSourcePanel()
        {
            m_model.Fill();
            m_model.Render();

            Assert.That(m_sourcePanel, Is.EqualTo("Product 1 available; Product 2 available; Product 3 available; "));
        }
    }
}

Ok, es kompiliert endlich! Aber wir gehen ja nach TDD vor, der Test ist wie gew├╝nscht rot :D. Die 2 Methoden Fill und Render sind noch nicht implementiert.
Was sollen die Methoden tun? Fill() sollte eine lokale Liste mit Hilfe der Deposit-Repository f├╝llen und Render() soll diese Elemente in das SourcePanel-Feld der View schreiben. Also muss unser Modell eine Liste, das IDeposit-Interface und das IShoppingVew als neue Member bekommen. Letzteren werden nat├╝rlich injectet (s. Dependency Inversion):

   public class ShoppingModel
   {
      IDeposit m_deposit;
      IList<Product> m_products;
      [NonSerialized]IShoppingView m_view;

      public ShoppingModel(IDeposit deposit)
      {
         m_deposit = deposit;
      }

      public void SetView( IShoppingView view )
      { 
         m_view = view;
      }
      public void Fill()
      {
         m_products = m_deposit.Load();
      }
      public void Render()
      {
         foreach( Product product in m_products )
         {
            m_view.AddSourceItem( product.Name, true );
         }
      }
   }

   [TestFixture]
   public class ShoppingCartTests:IShoppingView,IDeposit
   {
      ...
      private ShoppingModel m_model;

      [SetUp]
      public void Setup()
      {
         m_model = new ShoppingModel(this);
         m_model.SetView( this );
         m_sourcePanel = string.Empty;
         m_cartPanel = string.Empty;
      }

      [Test]
      public void FillSourcePanel()
      {
         m_model.Fill();
         m_model.Render();

         Assert.That( m_sourcePanel, Is.EqualTo( "Product 1 available; Product 2 available; Product 3 available; " ) );
      }
      ...
   }

Der Test ist gr├╝n! Jetzt ist sicher klar wie es weitergeht und ich will den Artikel nicht noch l├Ąnger machen. Hier sind also die n├Ąchsten Tests und die Implementierung dazu:

   [TestFixture]
   public class ShoppingCartTests:IShoppingView,IDeposit
   {
      private string m_sourcePanel;
      private string m_cartPanel;
      private IList<Product> m_products = new List<Product> { new Product( "Product 1", 1 ), new Product( "Product 2", 2 ), new Product( "Product 3", 3 ) };
      private ShoppingModel m_model;

      [SetUp]
      public void Setup()
      {
         m_model = new ShoppingModel(this, new Cart());
         m_model.SetView( this );
         m_sourcePanel = string.Empty;
         m_cartPanel = string.Empty;
      }
...
      [Test]
      public void AddAnItem()
      {
         m_model.Fill();
         m_model.AddAt( 0 );
         m_model.Render();

         Assert.That( m_sourcePanel, Is.EqualTo( "Product 1 available; Product 2 available; Product 3 available; " ) );
         Assert.That( m_cartPanel, Is.EqualTo( "Product 1 " ) );
      }

      [Test]
      public void AddTwoItemsOfAKind()
      {
         m_model.Fill();
         m_model.AddAt( 0 );
         m_model.AddAt( 0 );
         m_model.Render();

         Assert.That( m_sourcePanel, Is.EqualTo( "Product 1 Product 2 available; Product 3 available; " ) );
         Assert.That( m_cartPanel, Is.EqualTo( "Product 1 Product 1 " ) );
      }

      [Test]
      public void AddThreeDifferentItems()
      {
         m_model.Fill();
         m_model.AddAt( 0 );
         m_model.AddAt( 2 );
         m_model.AddAt( 1 );
         m_model.Render();

         Assert.That( m_sourcePanel, Is.EqualTo( "Product 1 Product 2 Product 3 " ) );
         Assert.That( m_cartPanel, Is.EqualTo( "Product 1 Product 3 Product 2 " ) );
      }
...
      void IShoppingView.AddCartItem( string text )
      {
         m_cartPanel += text + " ";
      }
   }
   public class ShoppingModel
   {
      IDeposit m_deposit;
      IList<Product> m_products;
      ICart m_cart;
      [NonSerialized] IShoppingView m_view;

      public ShoppingModel(IDeposit deposit, ICart cart)
      {
         m_deposit = deposit;
         m_cart = cart;
         m_view = view;
         m_products = new List<Product>();
      }
      public void SetView( IShoppingView view )
      { 
         m_view = view;
      }

      public void Fill()
      {
         m_products = m_deposit.Load();
      }

      public void Render()
      {
         foreach( Product product in m_products )
         {
            m_view.AddSourceItem( product.Name, m_cart.IsOkToAdd(product) );
         }
         foreach( Product product in m_cart.List )
         {
            m_view.AddCartItem( product.Name );
         }
      }

      public void AddAt( int index )
      {
         var product = m_products[index];
         m_cart.Add( product );
      }
   }

   public interface ICart
   {
      bool IsOkToAdd( Product product );
      void Add( Product product );
      IList<Product> List { get; }
   }

   public class Cart :ICart{

      private IList<Product> m_cartItems = new List<Product>();

      public bool IsOkToAdd( Product product )
      {
         return m_cartItems.Where( a => a.Type == product.Type ).Count() < 2 && m_cartItems.Count < 3;
      }

      public void Add( Product product )
      {
         m_cartItems.Add( product );
      }

      public IList<Product> List
      {
         get { return m_cartItems; }
      }
   }

Die einzige gr├Â├čere ├änderung zum ersten Test ist das neue ICart-Objekt. Da es hier um mehr als es eine Liste geht (irgendwo muss ja die Logik der maximal 2 gleichen Produkte pro Warenkorb errechnet werden), habe ich daf├╝r das Interface und die Klasse definiert.

Jetzt sind wir fast fertig. Es muss lediglich die abstrahierte Umgebung in eine Webanwendung nachgebaut werden. Das hei├čt, wir implementieren die Methoden Page_Load(), Pre_Render() und AddAt_Click() und die Methoden des Interface IShoppingView. Um die Kontrolle zu behalten, l├Âschen wir den Designer und schalten den ViewState aus (deswegen mag ich diesen Ingemar so sehr ­čśë ).

//default.aspx
<%@ Page Language="C#" AutoEventWireup="true" EnableViewState="false" CodeBehind="Default.aspx.cs" Inherits="ShoppingCart.Web._Default" %>

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>Shopping Cart</title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
    <asp:Panel runat="server" ID="srcPanel"></asp:Panel>
    <asp:Panel runat="server" ID="cartPanel"></asp:Panel>
    </div>
    </form>
</body>
</html>

//default.aspx.cs
using System;
using System.Collections.Generic;
using System.Web.UI.HtmlControls;
using System.Web.UI.WebControls;

namespace ShoppingCart.Web
{
   public class _Default : System.Web.UI.Page, IShoppingView
   {
      protected ShoppingModel model;
      protected HtmlTable srcTable, cartTable;
      protected Panel srcPanel, cartPanel;

      protected void Page_Load( object sender, EventArgs e )
      {
         if( !IsPostBack )
         {
            model = new ShoppingModel(new FakeDeposit(),new Cart());
            //Speichern, hier in Session aber sonst nat├╝rlich mit einer Repository
            Session["ShoppingModel"] = model;
            model.Fill();
         }
         else
         {
            model = (ShoppingModel)Session["ShoppingModel"];
         }
         model.SetView( this );
         ModelRender();
      }

      protected void Page_PreRender()
      {
         srcPanel.Controls.Clear();
         cartPanel.Controls.Clear();
         ModelRender();
      }

      private void ModelRender()
      {
         srcTable = new HtmlTable();
         srcPanel.Controls.Add( srcTable );
         srcTable.Width = "50%";
         srcTable.Border = 1;

         cartTable = new HtmlTable();
         cartPanel.Controls.Add( cartTable );
         cartTable.Width = "50%";
         cartTable.Border = 1;
         cartTable.BgColor = "#cccccc";

         model.Render();
      }
      public void AddSourceItem( string text, bool available )
      {
         int index = srcTable.Rows.Count;
         HtmlTableRow tr = new HtmlTableRow();
         HtmlTableCell tc = new HtmlTableCell { InnerText = text };
         if( available )
         {
            LinkButton lb = new LinkButton();
            tc.Controls.Add( lb );
            lb.ID = index.ToString();
            lb.Text = ">>";
            lb.Click += AddAt_Click;
         }
         tr.Cells.Add( tc );
         srcTable.Rows.Add( tr );
      }
      private void AddAt_Click( object sender, EventArgs e )
      {
         model.AddAt( Convert.ToInt32( ((LinkButton)sender).ID ) );
      }
      public void AddCartItem( string text )
      {
         HtmlTableCell tc = new HtmlTableCell { InnerText = text };
         HtmlTableRow tr = new HtmlTableRow();
         tr.Cells.Add( tc );
         cartTable.Rows.Add( tr );
      }
   }

   internal class FakeDeposit :IDeposit
   {
      public IList<Product> Load()
      {
         return new List<Product> { new Product( "Product 1", 1 ), new Product( "Product 2", 2 ), new Product( "Product 3", 3 ) };
      }
   }
}

Fertig. Ich muss eingestehen, als ich das Beispiel aus dem Buch nachprogrammiert habe, war ich wirklich ├╝berrascht, wie alles geklappt hat, obwohl ich w├Ąhrend des Testens keine Webseite angesprochen habe. Die Wahrheit ist, ich habe noch nie nach dem MVP-Pattern entwickelt, aber eine Webseite so aufzusetzen ist genial! Hoch lebe die Abstraktion!

Ich lade hier das Projekt hoch, vielleicht glaubt es mir jemand nicht ­čśë

Specification Pattern

Seitdem ich die praktische Anwendung des von Eric Evans in Domain-Driven Design beschriebenen Spezifikationsmusters in Jimmy Nilsons Buch gesehen habe, bin ich ein gro├čer Fan geworden.

SPECIFICATION provides a concise way of expressing certain kinds of rules, extricating them from conditional logic and making them explicit in the model.

Genau dasselbe Prinzip habe ich in diesem Artikel angewendet und ich nutze dieser Vorgehensweise laufend.

  • Wann braucht man eine Spezifikation?
    Immer, wenn ein Domain-Objekt bestimmte Erwartungen erf├╝llen muss, zum Beispiel beim Validieren (wie in o.g. Artikel) oder bei der Suche anhand von bestimmten Kriterien.
  • namespace Specification
    {
        public interface IValidable{}
    
        public class Invoice : IValidable{}
    
        public interface ISpecification
        {
            bool IsSatisfiedBy(IValidable obj);
        }
    
        public class BlackListClientsSpecification : ISpecification
        {
            private readonly DateTime m_currentDate;
    
            public DelinquentClientsSpecification(DateTime currentDate)
            {
                m_currentDate = currentDate;
            }
    
            public bool IsSatisfiedBy(IValidable obj)
            {
                Client candidate = obj as Client;
                //do something with Candidate and CurrentDate
                return true;
            }
        }
    }
    //Selektion:
    ...
        public class ClientRepository
        {
            IList<Client> SelectSatisfying(ISpecification specification)
            {
                return SelectAllClients().Where(a => specification.IsSatisfiedBy(a));
            }
        }
    ...
        var delinquentClients = clientRepository.SelectSatisfying(new DelinquentClientSpecification(currentDate));
    ...
    
  • Wozu braucht man eine Spezifikation?
    Ich kenne das aus eigener Erfahrung, wie sich Codeschnippsel (zum Beispiel obj.State==valid oder obj.Activ==true && obj.Created usw.), die verschiedenen Kriterien darstellen, wie Unkraut ├╝berall in Code verbreiten. Das kann man mit dieser L├Âsung wunderbar unterbinden, alle Bedingungen m├╝ssen in die jeweils passende Spezifikation gesammelt werden.

Man kann als Basis ein Interface, ( ISpecification ) oder eine abstrakte, an das beschriebene Domain Objekt angepasste Klasse InvoiceSpecification nutzen, abh├Ąngig davon, ob man nur einen Kontrakt oder auch Code wiederverwenden will.
Aus der Sicht des Testens, sind nat├╝rlich diese Klassen ideal, sie haben keine Abh├Ąngigkeiten, sind pure logische Ausdr├╝cke der Entscheidungen z.B. der Gesch├Ąftsleitung. F├╝r diese Klassen wurde TDD erfunden ;).

Kontextabh├Ąngige Datenvalidierung

Die Idee stammt von Jimmy Nilsson – Applying Domain-Driven Design and Patterns. Er hat nach einer M├Âglichkeit gesucht, die immer wiederkehrende Aufgabe, Daten zu validieren, flexibel und kontextabh├Ąngig zu gestalten, und zwar so, dass man es nur einmal schreiben muss.

Wie l├Ąuft normalerweise so eine Validierung ab? Man will wissen, ob eine Instanz als solche allen Vorschriften entspricht, und wenn nicht, dann welche Felder passen nicht. Jeder, der jemals Webanwendungen geschrieben hat, wei├č, wie m├╝hsam und langweilig es ist, jeden Eingabewert auf G├╝ltigkeit zu testen. (Hier geht allerdings nicht unbedingt um Formulare, da kann man ja die Validierung z.B. bei ASP.MVC 2.0 mit Data Annotations durchf├╝hren.)

Also zur├╝ck zu den Anforderungen: um die verschiedenen Regeln wiederverwendbar zu machen, braucht man diese von einem Interface abzuleiten:

namespace ValidationFramework
{
    public interface IRule
    {
        bool IsValid { get; }
        int IdRule { get; }
        string[] BooleanFieldsThatMustBeTrue { get; }
        string Message { get; }
    }
}

IsValid sagt aus, ob der Regel verletzt wurde. Die IdRule ist daf├╝r da, um diese Regeln einfacher identifizieren zu k├Ânnen. BooleanFieldsThatMustBeTrue kann daf├╝r verwendet werden, um Vorbedingungen zu pr├╝fen. Message braucht wohl keine Erkl├Ąrung.
Jetzt kann man verschiedene Regeln und eine Basisklasse f├╝r gemeinsame Funktionalit├Ąten definieren:

using System.Collections.Generic;
using System.Linq;
using System;

namespace ValidationFramework
{
    public abstract class RuleBase : IRule
    {
        private readonly object m_value;
        private readonly int m_idRule;
        private readonly string[] m_booleanFieldsThatMustBeTrue;
        private readonly object m_holder;

        protected RuleBase(int idRule, string[] fieldsConcerned, string fieldname, object holder)
        {
            m_value = GetPropertyValue(holder, fieldname);
            m_booleanFieldsThatMustBeTrue = fieldsConcerned;
            m_holder = holder;
            m_idRule = idRule;
        }

        private static object GetPropertyValue(object holder, string fieldname)
        {
            return holder.GetType().GetProperty(fieldname).GetValue(holder, null);
        }

        protected object GetValue()
        {
            return m_value;
        }
        protected object GetHolder()
        {
            return m_holder;
        }

        public abstract bool IsValid { get; }
        public int IdRule
        {
            get { return m_idRule; }
        }

        public string[] BooleanFieldsThatMustBeTrue
        {
            get { return m_booleanFieldsThatMustBeTrue; }
        }

        public abstract string Message { get; }

        protected bool BooleanFieldsConcernedAreTrue()
        {
            return
                m_booleanFieldsThatMustBeTrue.Select(a => (bool)m_holder.GetType().GetProperty(a).GetValue(m_holder, null)).
                    Select(b => b).Count() == m_booleanFieldsThatMustBeTrue.Length;
        }
    }

    public class DateIsInRangeRule : RuleBase
    {
        private readonly DateTime m_minDate;
        private readonly DateTime m_maxDate;

        public DateIsInRangeRule(DateTime minDate, DateTime maxDate, int idRule, string fieldName, object holder) : base( idRule, null,fieldName, holder)
        {
            m_minDate = minDate;
            m_maxDate = maxDate;
        }

        public override bool IsValid
        {
            get { 
                var value = (DateTime) GetValue();
                return value >= m_minDate && value <= m_maxDate;
            }
        }

        public override string Message
        {
            get {
                return IsValid
                           ? string.Empty
                           : string.Format("Das Datum ist nicht in g├╝ltigen Bereich: {0}-{1}", m_minDate, m_maxDate); }
        }
    }

    public class MaxStringLengthRule : RuleBase
    {
        private readonly int m_maxLength;

        public MaxStringLengthRule(int maxLength, int idRule, string fieldname, object holder) : base(idRule, null, fieldname, holder)
        {
            m_maxLength = maxLength;
        }

        public override bool IsValid
        {
            get { return GetValue().ToString().Length <= m_maxLength; }
        }

        public override string Message
        {
            get {
                return IsValid
                           ? string.Empty
                           : string.Format("Die zugelassene L├Ąnge von {0} Zeichen wurde ├╝berschritten",m_maxLength); }
        }
    }
}

Jetzt, da die Grundlagen stehen, schauen wir mal, wie man die Validierungsregeln festlegen w├╝rde.
Hier ist eine ganz einfache Beispielklasse:

using System;

namespace ValidationFramework
{
    public class Account
    {
        public Account()
        {
            Created = DateTime.Now;
            Address = string.Empty;
        }

        public DateTime Created { set; get; }
        public string Address { get; set; }
        public bool Activated { get; set; }
    }
}

Jetzt definieren wir die Regeln, wonach eine Instanz valide ist oder nicht. Die neue Eigenschaft IsValidated soll diese Information speichern.

    public class Account
    {
        private readonly IList<IRule> m_validationRules = new List<IRule>();

        public Account()
        {
            Created = DateTime.Now;
            Address = string.Empty;
        }

        public DateTime Created { set; get; }
        public string Address { get; set; }
        public bool Activated { get; set; }
        public bool IsValidated { get; set; }

        private void SetupValidationRules()
        {
            m_validationRules.Add(new DateIsInRangeRule(new DateTime(1990,1,1),DateTime.Now,1,"Created",this ));
            m_validationRules.Add(new MaxStringLengthRule(10,2,"Address",this));
        }
    }

Um Regeln auch dynamisch setzen zu k├Ânnen, wird eine Methode AddValidationRule(IRule) definiert

 
    public class Account
    {
...    
        public void AddValidationRule(IRule rule)
        {
            m_validationRules.Add(rule);
        }
...
    }

Nun m├╝ssen wir diese Regeln nur noch auswerten. Daf├╝r wird in RuleBase eine statische Methode definiert und in der Beispielklasse die Methode IEnumerable GetBrokenRules()

    public abstract class RuleBase : IRule
    {
...
        public static IEnumerable<IRule> CollectBrokenRules(IList<IRule> rulesToCheck)
        {
            return rulesToCheck.Where(a => !a.IsValid).Select(a => a);
        }
    }
    public class Account
    {
...
        public IEnumerable<IRule> GetBrokenRules()
        {
            SetupValidationRules();
            return RuleBase.CollectBrokenRules(m_validationRules);
        }
...
    }

Um zu beweisen, dass es funktioniert, hier ein Paar Tests:

using System;
using System.Linq;
using NUnit.Framework;

namespace ValidationFramework.Tests
{
    [TestFixture]
    [Category("DateIsInRangeRule")]
    public class If_the_CreationDate_of_the_Account_is_in_range
    {
        [Test]
        public void Then_the_property_Created_is_valid()
        {
            var sut = new Account { Created = DateTime.Now.AddYears(-1) };
            Assert.That(sut.GetBrokenRules().Count(),Is.EqualTo(0));
        }
    }
    [TestFixture]
    [Category("DateIsInRangeRule")]
    public class If_the_CreationDate_of_the_Account_is_to_old
    {
        [Test]
        public void Then_the_property_Created_is_not_valid()
        {
            var sut = new Account { Created = new DateTime(1989,1,1)};
            Assert.That(sut.GetBrokenRules().Count(), Is.EqualTo(1));
            Assert.That(sut.GetBrokenRules().First().IdRule, Is.EqualTo(1));
        }
    }

    [TestFixture]
    [Category("MaxStringLengthRule")]
    public class If_the_Address_of_the_Account_is_to_long
    {
        [Test]
        public void Then_the_property_Address_is_not_valid()
        {
            var sut = new Account { Address = "12345678901"};
            Assert.That(sut.GetBrokenRules().Count(), Is.EqualTo(1));
            Assert.That(sut.GetBrokenRules().First().IdRule,Is.EqualTo(2));
        }
    }
}

Mit den vorhandenen Tests kann man nun refaktorisieren um die Prinzipien der Separation Of Concern einzuhalten. Au├čerdem ist nun Zeit, auch ├╝ber die Kontextbezogenheit nachzudenken.
Die Klasse Account wird wahrscheinlich durch irgendeinen ORMapper gef├╝llt und braucht auf keinem Fall die Verantwortung, die Validierungsregeln zu verwalten. Deshalb kann man das Specification-Pattern von DDD anwenden, und diese Regeln in so eine Spezifikation verschieben:

using System;
using System.Collections.Generic;

namespace ValidationFramework
{
    public interface IValidationSpecification
    {
        IList<IRule> GetValidationRules();
    }

    public class AccountValidationSpecification : IValidationSpecification
    {
        private readonly Account m_objectToValidate;

        public AccountValidationSpecification(object objectToValidate)
        {
            m_objectToValidate = (Account) objectToValidate;
        }

        public IList<IRule> GetValidationRules()
        {
            return new List<IRule>
                       {
                           new DateIsInRangeRule(new DateTime(1990, 1, 1), DateTime.Now, 1, "Created",
                                                 m_objectToValidate),
                           new MaxStringLengthRule(10, 2, "Address", m_objectToValidate)
                       };
        }
    }
}

Die Spezifikationen werden selbstverst├Ąndlich von einer Factory geliefert und sie werden per Setter Injection gesetzt.

    public  class ValidationSpecificationFactory
    {
        public static IValidationSpecification Create<T>(object objectToValidate)
        {
            if (typeof(T) == typeof(Account))
                return new AccountValidationSpecification(objectToValidate);
            throw new NotSupportedException();
        }
    }
    public class Account
    {
...
        public void SetValidationSpecification(IValidationSpecification specification)
        {
            foreach (IRule rule in specification.GetValidationRules())
                m_validationRules.Add(rule);
        }
...
    }
//Der Aufruf ist dann
var account = new Account();
account.SetValidationSpecification(ValidationSpecificationFactory.Create<Account>(account));

Dadurch ist die Bedingung, Kontextabh├Ąngige Validierungsregeln festlegen zu k├Ânnen, erf├╝llt.

Man kann generische Spezifikationen definieren, die die Regeln f├╝r verschiedene Zwecke, z.B. f├╝r Persistieren oder auch einfach nur f├╝r Akzeptieren definieren:

   
    public interface IValidationSpecification
    {
        IList<IRule> GetValidationRules();
        IList<IRule> GetValidationRulesRegardingPersistence();
    }

Hier der komplette Quellcode zum Herunterladen.