Setting up StructureMap and The Unit Of Work ActionFilter

UnitOfWork ActionFilter

In my previous post I had created the repository implementations along with unit of work. But how do we use this unit of work in our application. ASP.NET MVC has a concept of ActionFilters. These could be applied to an action or a controller in general. The two main methods that concern us are OnActionExecuting and the OnActionExecuted. As seen in the code below we call the initialize method of the unit of work which would create a new transaction for us and this is held until the action is complete after which we commit the transaction. We are getting a new instance of _unitOfWork through an IoC container which I will talk about in a bit.

namespace MPBlog.Web.UI.ActionFilters
{
    using System;
    using System.Web.Mvc;
    using Core.BaseClasses;
    using StructureMap;
 
    public class UseUnitOfWOrkAttribute : ActionFilterAttribute
    {
        private readonly IUnitOfWork _unitOfWork;
 
        public UseUnitOfWOrkAttribute()
        {
            _unitOfWork = ObjectFactory.GetInstance<IUnitOfWork>();
        }
 
        public UseUnitOfWOrkAttribute( IUnitOfWork unitOfWork )
        {
            _unitOfWork = unitOfWork;
        }
 
        public override void OnActionExecuting( ActionExecutingContext filterContext )
        {
            _unitOfWork.Initialize();
        }
 
        public override void OnActionExecuted( ActionExecutedContext filterContext )
        {
            try
            {
                _unitOfWork.Commit();
            }
            catch( Exception )
            {
                _unitOfWork.Rollback();
                throw;
            }
            finally
            {
                _unitOfWork.Dispose();
            }
        }
    }
}

We use this action filter either by decoration individual action with the attribute or if we want all actions to use the unit of work, then we can decorate the class itself with the attribute. In the following code I am using the UseUnitOfWork filter on the Index action.

namespace MPBlog.Web.UI.Controllers
{
    using System.Web.Mvc;
    using ActionFilters;
    using Core.Services;
 
    [HandleError]
    public class HomeController : Controller
    {
        private readonly IBlogService _blogService;
 
        public HomeController(IBlogService blogService)
        {
            _blogService = blogService;
        }
 
        [UseUnitOfWOrk]
        public ActionResult Index()
        {
            var posts = _blogService.GetAllPosts();
            return View(posts);
        }
    }
}

Attributes may look a bit intrusive (atleast for me). I like how FubuMVC handles this. In FubuMVC, we have something called behaviors and this can be configured in the application start. So if we want all our actions to use the unit of work, then we can set the behavior as shown below and that's it, no more attributes on the action or controller. In the following code the access_the_database_through_a_unit_of_work has the same implementation as the filter we created.

ControllerConfig.Configure = x =>
{
    // Default Behaviors for all actions -- ordered as they're executed
    /////////////////////////////////////////////////
    x.ByDefault.EveryControllerAction(d => d
        .Will<access_the_database_through_a_unit_of_work>()
        );
};

Services

Instead of accessing the repository directly from the controllers, I have created a separate service which delegates the work to the repository to the operations related. Following is an example of a blog service. I have kept the methods to be minimal for brevity.

namespace MPBlog.Core.Services
{
    using System.Collections.Generic;
    using Domain;
 
    public interface IBlogService
    {
        IEnumerable<Post> GetAllPosts();
        IEnumerable<Post> GetPostsByTag(string tag);
        Post GetPostById( int postID );
        Post GetPostBySlug( string slug );
 
        void SavePost( Post post );
        void UpdatePost( Post post );
        void DeletePost( Post post );
    }
}

namespace MPBlog.Core.Services
{
    using System.Collections.Generic;
    using System.Linq;
    using BaseClasses;
    using Domain;
 
    public class BlogService : IBlogService
    {
        private readonly IRepository _repository;
 
        public BlogService( IRepository repository )
        {
            _repository = repository;
        }
 
        public IEnumerable<Post> GetAllPosts()
        {
            return _repository.Query<Post>().AsEnumerable();
        }
 
        public IEnumerable<Post> GetPostsByTag( string tag )
        {
            return
                _repository.Query<Tag>( t => t.Description.Equals( tag ) ).
                    SingleOrDefault().Posts;
        }
 
        public Post GetPostById( int postId )
        {
            return _repository.Load<Post>( postId );
        }
 
        public Post GetPostBySlug( string slug )
        {
            return _repository.Query<Post>( p => p.PostSlug.Equals( slug ) ).SingleOrDefault();
        }
 
        public void SavePost( Post post )
        {
            _repository.Save( post );
        }
 
        public void UpdatePost( Post post )
        {
            _repository.Save( post );
        }
 
        public void DeletePost( Post post )
        {
            _repository.Delete( post );
        }
    }
}

Dependency Injection using StructureMap

If we look at the all the code that has been shown till now, we see that, there is almost always an interface declared and we can nowhere see a direct instantiation of the object that is required. So how do we get a new instance of an object. This is where an Inversion Of Control (IoC/DI)  container comes into play. Basically what it does is to give you a concrete objects whenever we require.

I have used constructor injection where ever possible. How it works is, by defining our own ControllerFactory and create the controller ourselves instead of ASP.NET MVC doing it for us. In the below code I have a StrucutreMapControllerFactory from where I am getting an instance of the controller. This factory inherits from the DefaultControllerFactory for ASP.NET MVC and we override the controller building method.

namespace MPBlog.Web.UI.Controllers
{
    using System;
    using System.Web.Mvc;
    using StructureMap;
 
    public class StructureMapControllerFactory : DefaultControllerFactory
    {
        protected override IController GetControllerInstance(Type controllerType)
        {
            IController result = null;
            if (controllerType != null)
            {
                try
                {
                    result = ObjectFactory.GetInstance(controllerType) as Controller;
 
                }
                catch (StructureMapException)
                {
                    System.Diagnostics.Debug.WriteLine(ObjectFactory.WhatDoIHave());
                    throw;
                }
            }
            return result;
        }
    }
}

We set this controller factory in our Application_Start method in the global.asax file like so.

RegisterRoutes( RouteTable.Routes );
Bootstrapper.Bootstrap();
ControllerBuilder.Current.SetControllerFactory(
    new StructureMapControllerFactory());

namespace MPBlog.Web.UI
{
    using StructureMap;
 
    public class Bootstrapper : IBootstrapper
    {
        public void BootstrapStructureMap()
        {
            ObjectFactory.Initialize( x => x.AddRegistry( new MPBlogRegistry() ));
        }
 
        public static void Bootstrap()
        {
            new Bootstrapper().BootstrapStructureMap();
        }
    }
}

using System.Configuration;
 
namespace MPBlog.Web.UI
{
    using Core.BaseClasses;
    using Core.Services;
    using FluentNHibernate;
    using Persistence;
    using Persistence.Config;
    using Persistence.RepositoryImpl;
    using Persistence.UnitOfWork;
    using StructureMap.Attributes;
    using StructureMap.Configuration.DSL;
 
    public class MPBlogRegistry : Registry
    {
        public MPBlogRegistry()
        {
            ForRequestedType<ISessionSource>().AsSingletons()
                .TheDefault.Is.ConstructedBy( context =>
                    context.GetInstance<ISessionSourceConfiguration>()
                    .CreateSessionSource( new MPBlogPersistenceModel() ) );
 
            ForRequestedType<ISessionSourceConfiguration>().AsSingletons()
                .TheDefault.Is.OfConcreteType<SQLSessionSourceConfiguration>()
                .WithCtorArg( "connectionString" )
                    .EqualTo( ConfigurationManager.ConnectionStrings["MPBlog"].ConnectionString )
                .WithCtorArg( "resetDb" )
                    .EqualToAppSetting( "reset" );
 
            ForRequestedType<IUnitOfWork>()
                .TheDefault.Is.ConstructedBy( context => context.GetInstance<INHibernateUnitOfWork>() );
 
            ForRequestedType<INHibernateUnitOfWork>().CacheBy( InstanceScope.Hybrid )
                .TheDefault.Is.OfConcreteType<NHibernateUnitOfWork>();
 
            ForRequestedType<IRepository>().AsSingletons()
                .TheDefault.Is.OfConcreteType<NHRepository>();
 
            ForRequestedType<IBlogService>().AsSingletons()
                .TheDefault.Is.OfConcreteType<BlogService>();
        }
    }
}

Once this is done whenever we ask for a instance of an object, the IoC toll will lookup and give us the concerned concrete object.

Thats it for now.

In my previous post we looked at the domain model and the class maps associated with it. In this post lets look at the Repository and Unit Of Work implementations.

Note: The following is based on the FubuMVC contrib project.

IRepository

A repository is an abstraction layer which gives your application an in memory domain object collection. This layer helps in making you application agnostic about where the data is coming from or where it is persisted into. It could well be a flat file or any other RDBMS. Preferably each of your domain object would have its own repository. But for the sake of keeping it simple, I am using a generic repository in the following code.

namespace MPBlog.Core.BaseClasses
{
    using System;
    using System.Linq;
    using System.Linq.Expressions;
 
    public interface IRepository
    {
        T Load<T>( int id ) where T : Entity<T>;
        void Delete<T>( T target );
        void Save<T>( T target );
        IQueryable<T> Query<T>() where T : Entity<T>;
        IQueryable<T> Query<T>( Expression<Func<T, bool>> whereQuery ) where T : Entity<T>;
    }
}

The Query methods here will be implemented using Linq to NHibernate. Now that we have the interface, lets look at the implementation.

NHRepository

namespace MPBlog.Persistence.RepositoryImpl
{
    using System;
    using System.Linq;
    using System.Linq.Expressions;
    using Core.BaseClasses;
    using NHibernate.Linq;
    using UnitOfWork;
 
    public class NHRepository : IRepository
    {
        private INHibernateUnitOfWork _unitOfWork;
 
        public NHRepository( INHibernateUnitOfWork unitOfWork )
        {
            _unitOfWork = unitOfWork;
        }
 
        public T Load<T>( int id ) where T : Entity<T>
        {
            return _unitOfWork.Session.Load<T>( id );
        }
 
        public void Delete<T>(T target)
        {
            _unitOfWork.Session.Delete( target );
        }
 
        public void Save<T>(T target)
        {
            _unitOfWork.Session.Save( target );
        }
 
        public IQueryable<T> Query<T>() where T : Entity<T>
        {
            return _unitOfWork.Session.Linq<T>();
        }
 
        public IQueryable<T> Query<T>(Expression<Func<T, bool>> whereQuery) where T : Entity<T>
        {
            return _unitOfWork.Session.Linq<T>().Where( whereQuery );
        }
    }
}

If you notice the above code, we are accessing the session through the unitofwork. A unit of work helps in keeping track of all the objects that are affect by a business transaction. Following is the implementation of the UnitOfWork.

IUnitOfWork and INHibernateUnitOfWork

namespace MPBlog.Core.BaseClasses
{
    using System;
 
    public interface IUnitOfWork : IDisposable
    {
        void Initialize();
        void Commit();
        void Rollback();
    }
}

namespace MPBlog.Persistence.UnitOfWork
{
    using Core.BaseClasses;
    using NHibernate;
 
    public interface INHibernateUnitOfWork : IUnitOfWork
    {
        ISession Session { get; }
    }
}

NHibernateUnitOfWork

namespace MPBlog.Persistence.UnitOfWork
{
    using System;
    using FluentNHibernate;
    using NHibernate;
 
    public class NHibernateUnitOfWork : INHibernateUnitOfWork
    {
        private ITransaction _transaction;
        private readonly ISessionSource _source;
        private bool _isDisposed;
        private bool _isInitialized;
 
        public ISession Session { get; private set; }
 
        public NHibernateUnitOfWork( ISessionSource source )
        {
            _source = source;
        }
 
        public void Initialize()
        {
            CheckUoWSanity();
 
            Session = _source.CreateSession();
            StartNewTransaction();
 
            _isInitialized = true;
        }
 
        public void Commit()
        {
            CheckUoWSanity();
            CheckUoWInitialization();
 
            _transaction.Commit();
 
            StartNewTransaction();
        }
 
        public void Rollback()
        {
            CheckUoWSanity();
            CheckUoWInitialization();
 
            _transaction.Rollback();
 
            StartNewTransaction();
        }
 
        public void Dispose()
        {
            if( _isDisposed || !_isInitialized )
                return;
 
            _transaction.Dispose();
            Session.Dispose();
 
            _isDisposed = true;
        }
 
        private void CheckUoWSanity()
        {
            if( _isDisposed )
            {
                throw new ObjectDisposedException( "Trying to use disposed object" );
            }
        }
 
        private void CheckUoWInitialization()
        {
            if( !_isInitialized )
            {
                throw new InvalidOperationException( "NHibernateUnitOfWork is not initialized" );
            }
        }
 
        private void StartNewTransaction()
        {
            if( _transaction != null )
            {
                _transaction.Dispose();
            }
 
            _transaction = Session.BeginTransaction();
        }
    }
}

Tests

Following are the test that were written for both the repository and unitofwork. I am using MoQ as my mocking framework so that I don't have to connect to the actual database when testing.

namespace MPBlog.Tests.Persistence.Tests
{
    using System.Linq;
    using Core.Domain;
    using Moq;
    using MPBlog.Persistence.RepositoryImpl;
    using MPBlog.Persistence.UnitOfWork;
    using NHibernate;
    using Xunit;
 
    public class RepositoryTests
    {
        private Mock<ISession> _session;
        private Mock<INHibernateUnitOfWork> _uow;
        private Mock<NHRepository> _repo;
 
        public RepositoryTests()
        {
            _session = new Mock<ISession>();
            _uow = new Mock<INHibernateUnitOfWork>();
            _uow.Setup( u => u.Session ).Returns( _session.Object );
            _repo = new Mock<NHRepository>( _uow.Object );
        }
 
        [Fact]
        public void Call_to_load_should_load_object_from_the_session()
        {
            var postId = 1;
            _repo.Object.Load<Post>( postId );
            _session.Verify( s => s.Load<Post>( postId ), Times.AtLeastOnce() );
        }
 
        [Fact]
        public void Call_to_save_should_save_object_on_the_session()
        {
            var post = new Post();
            _repo.Object.Save( post );
            _session.Verify( s => s.SaveOrUpdate( post ), Times.AtLeastOnce() );
        }
 
        [Fact]
        public void Call_to_delete_should_delete_object_from_the_session()
        {
            var post = new Post();
            _repo.Object.Delete( post );
            _session.Verify( s => s.Delete( post ), Times.AtLeastOnce() );
        }
 
        [Fact]
        public void Call_to_query_on_session_should_return_an_IQueryable_object()
        {
            Assert.IsAssignableFrom( typeof( IQueryable<Post> ), _repo.Object.Query<Post>() );
        }
    }
}

namespace MPBlog.Tests.Persistence.Tests
{
    using FluentNHibernate;
    using Moq;
    using MPBlog.Persistence.UnitOfWork;
    using NHibernate;
    using Xunit;
 
    public class UnitOfWorkTests
    {
        protected Mock<ISession> _session;
        protected Mock<ITransaction> _transaction;
        protected Mock<ISessionSource> _sessionSource;
        protected Mock<NHibernateUnitOfWork> _uow;
 
        public UnitOfWorkTests()
        {
            _session = new Mock<ISession>();
            _transaction = new Mock<ITransaction>();
            _sessionSource = new Mock<ISessionSource>();
 
            _sessionSource.Setup( s => s.CreateSession() ).Returns( _session.Object );
            _session.Setup( s => s.BeginTransaction() ).Returns( _transaction.Object );
 
            _uow = new Mock<NHibernateUnitOfWork>( _sessionSource.Object );
            _uow.Object.Initialize();
        }
 
        [Fact]
        public void Can_create_new_transaction()
        {
            _session.Verify( s => s.BeginTransaction(), Times.AtLeastOnce() );
        }
 
        [Fact]
        public void Can_dispose_the_transaction()
        {
            _uow.Object.Dispose();
            _transaction.Verify( s => s.Dispose(), Times.Exactly( 1 ) );
        }
 
        [Fact]
        public void Can_dispose_the_session()
        {
            _uow.Object.Dispose();
            _session.Verify( s => s.Dispose(), Times.Exactly( 1 ) );
        }
 
        [Fact]
        public void Call_to_commit_should_commit_the_transaction()
        {
            _uow.Object.Commit();
            _transaction.Verify( t => t.Commit(), Times.AtLeastOnce() );
        }
 
        [Fact]
        public void Call_to_commit_should_dispose_the_transaction_and_start_a_new_transaction()
        {
            _uow.Object.Commit();
            _transaction.Verify( t => t.Dispose(), Times.Exactly( 1 ) );
            _session.Verify( s => s.BeginTransaction(), Times.Exactly( 2 ) );
        }
 
        [Fact]
        public void Call_to_rollback_should_rollback_the_transaction()
        {
            _uow.Object.Rollback();
            _transaction.Verify( t => t.Rollback(), Times.AtLeastOnce() );
        }
 
        [Fact]
        public void Call_to_rollback_should_dispose_the_transaction_and_start_a_new_transaction()
        {
            _uow.Object.Rollback();
            _transaction.Verify( t => t.Dispose(), Times.Exactly( 1 ) );
            _session.Verify( s => s.BeginTransaction(), Times.Exactly( 2 ) );
        }
    }
}

As mentioned in my previous post, this series will no longer be a talk about DDD as a blog app is too trivial to show ( learn ) the power of it. I will be using some of the patterns of DDD though. So I have changed the name of the app I am building. It will be called MyPersonalBlog ( MPBlog ) henceforth.

The project structure has changed a bit from what I had shown here. There is no longer separate layers for infrastructure and domain. I have clubbed these 2 layers into a single Core layer. The other layers are just the same.

Lets get started by creating our domain objects.

The domain objects

So far we have created a entity base class from which all our domain ( models ) will inherit from. In a blog application, we’ll have posts, tags and comments. So lets create classes for each of these. I have created these classes as shown in the class diagram below.

From the diagram you can see that there is a many-to-many relation between Tag and Post class..

Domain mappings

I am using Fluent NHibernate to configure the mappings of these classes to the database. Although you can map all the classes using the automapping feature which has a convention based API, I will use the mapping per class feature. Lets look at the mappings.

PostMap

namespace MPBlog.Persistence.DomainMap
{
    using Core.Domain;
    using FluentNHibernate.Mapping;
 
    public class PostMap : ClassMap<Post>
    {
        public PostMap()
        {
            WithTable( "Posts" );
 
            Id( p => p.Id, "PostId" )
                .WithUnsavedValue( 0 )
                .Access.AsReadOnlyPropertyThroughCamelCaseField()
                .GeneratedBy.Identity();
 
            Map( p => p.PostTitle ).Not.Nullable();
 
            //will be created as nvarchar(max)
            Map( p => p.PostText ).Not.Nullable()
                .WithLengthOf( 4001 );
 
            Map( p => p.ExcerptText ).Not.Nullable()
                .WithLengthOf( 1000 );
            Map( p => p.PostSlug ).Unique();
            Map( p => p.AddedBy ).Not.Nullable();
            Map( p => p.PublishDate );
 
            // Many to many with an intermediate table ( PostsToTags )
            HasManyToMany( p => p.Tags )
                .WithTableName( "PostsToTags" )
                .Cascade.SaveUpdate();
            HasMany( p => p.Comments )
                .WithTableName( "Comments" )
                .Cascade.All().Inverse();
        }
    }
}

We create a PostMap class which inherits from the ClassMap<T>. The constructor of this PostMap class is where all out mappings go. As can be seen, first we specify the table name for our Posts, Then we specify the Id property which is mapped to the PostId column in our database. The Id in our case is the id that we had declared in the Entity base class ( I have renamed the Key property to Id ). If you recall from my previous post, it had only the getter property. The value is assigned by NHibernate. We specify a many to many relation between posts and tags through an intermediate table PostToTags. We have also specified that a post has many comments thought the Comments table The other mappings are self explanatory.

Out Tag and Comment mapping classes look similar to the one above. Following are the two mapping files for these.

TagMap

namespace MPBlog.Persistence.DomainMap
{
    using Core.Domain;
    using FluentNHibernate.Mapping;
 
    public class TagMap : ClassMap<Tag>
    {
        public TagMap()
        {
            WithTable( "Tags" );
 
            Id( t => t.Id, "TagId" )
                .WithUnsavedValue( 0 )
                .Access.AsReadOnlyPropertyThroughCamelCaseField()
                .GeneratedBy.Identity();
 
            Map( t => t.Description ).Not.Nullable();
            Map( t => t.CreatedDate );
 
            HasManyToMany( t => t.Posts )
                .WithTableName( "PostsToTags" )
                .Cascade.SaveUpdate();
        }
    }
}

CommentMap

namespace MPBlog.Persistence.DomainMap
{
    using Core.Domain;
    using FluentNHibernate.Mapping;
 
    public class CommentMap : ClassMap<Comment>
    {
        public CommentMap()
        {
            WithTable( "Comments" );
 
            Id( c => c.Id )
                .WithUnsavedValue( 0 )
                .Access.AsReadOnlyPropertyThroughCamelCaseField()
                .GeneratedBy.Identity();
 
            Map( c => c.Body ).Not.Nullable();
            Map( c => c.AuthorName ).Not.Nullable();
            Map( c => c.AuthorIP ).Not.Nullable();
            Map( c => c.AuthorEmail ).Not.Nullable();
            Map( c => c.AuthorUrl ).Not.Nullable();
            Map( c => c.AddedDate ).Not.Nullable();
 
            References( c => c.Post )
                .Not.Nullable()
                .Cascade.All();
        }
    }
}

Now that our mappings are done, lets create a SessionSource to access the NHibernate Session.

We can create a session through the ISessionSource interface in Fluent NHibernate. Lets create an interface for the SessionSourceConfiguration.

Note: The following is based on the FubuMVC contrib project.

ISessionSourceConfiguration and SessionSourceConfiguration

namespace MPBlog.Persistence.Config
{
    using FluentNHibernate;
 
    public interface ISessionSourceConfiguration
    {
        bool ResetDatabase { get; }
        ISessionSource CreateSessionSource( PersistenceModel model );
    }
}

namespace MPBlog.Persistence.Config
{
    using System.Collections.Generic;
    using FluentNHibernate;
    using FluentNHibernate.Cfg.Db;
 
    public class SessionSourceConfiguration : ISessionSourceConfiguration
    {
        private readonly string _connectionString;
        public bool ResetDatabase { get; private set; }
 
        public SessionSourceConfiguration( string connectionString, bool resetDb )
        {
            _connectionString = connectionString;
            ResetDatabase = resetDb;
        }
 
        public ISessionSource CreateSessionSource( PersistenceModel model )
        {
            var properties = GetProperties( _connectionString );
            var source = new SessionSource( properties, model );
 
            CreateDbWithSchema( source );
 
            return source;
        }
 
        public IDictionary<string, string> GetProperties( string connectionString )
        {
            return MsSqlConfiguration
                .MsSql2005
                .ConnectionString( c => c.Is( connectionString ) )
                .UseOuterJoin()
                .ShowSql()
                .ToProperties();
        }
 
        private void CreateDbWithSchema( ISessionSource source )
        {
            if( ResetDatabase )
            {
                source.BuildSchema();
            }
        }
    }
}

The ResetDatabase property is used to either create a new database from our mappings or reset the database. We have a method called GetProperties from which we generate the connection properties.

As you can see in the CreateSessionSource method, we are passing a PersistenceModel object. This object is used to add the mapping from a specified assembly, in our case, where we have defined the Post, Tag and Comment maps. Lets call it MPBlogPersistenceModel. Here is what it looks like.

using FluentNHibernate;
 
namespace MPBlog.Persistence
{
    public class MPBlogPersistenceModel : PersistenceModel
    {
        public MPBlogPersistenceModel()
        {
            addMappingsFromThisAssembly();
        }
    }
}

The PresistenceModel object, connectionString, and resetDB parameters are injected using an IoC container which we’ll have a look in a later post.

Following are the tests I have written to check my mapping are correct. I am using an in memory SQLite database and the PersistenceSpecification<T> provided by Fluent NHibernate to check my mapping.

Mapping Tests

namespace MPBlog.Tests.Persistence.Tests
{
    using System;
    using Core.Domain;
    using FluentNHibernate;
    using FluentNHibernate.Cfg.Db;
    using FluentNHibernate.Testing;
    using MPBlog.Persistence;
    using NHibernate;
    using Xunit;
 
    public class PersistenceTests
    {
        private ISession session;
        public PersistenceTests()
        {
            var persistenceModel = new MPBlogPersistenceModel();
 
            var config = new SQLiteConfiguration()
                .InMemory()
                .ConnectionString( c => c.Is( "Data Source=:memory:;Version=3;New=True;" ) )
                .ShowSql();
 
            var sessionSource = new SessionSource( config.ToProperties(), persistenceModel );
            session = sessionSource.CreateSession();
            sessionSource.BuildSchema( session );
        }
 
 
        [Fact]
        public void Post_mapping_test()
        {
            new PersistenceSpecification<Post>( session )
                .CheckProperty( p => p.AddedBy, "vinay" )
                .CheckProperty( p => p.PostTitle, "title" )
                .CheckProperty( p => p.PostText, "text" )
                .CheckProperty( p => p.ExcerptText, "text" )
                .CheckProperty( p => p.PostSlug, "slug" )
                .CheckProperty( p => p.PublishDate, DateTime.Today )
                .VerifyTheMappings();
        }
 
        [Fact]
        public void Tag_mapping_test()
        {
            new PersistenceSpecification<Tag>( session )
                .CheckProperty( t => t.Description, "tag1" )
                .CheckProperty( t => t.CreatedDate, DateTime.Today )
                .VerifyTheMappings();
        }
 
        [Fact]
        public void Comment_mapping_test()
        {
            new PersistenceSpecification<Comment>( session )
                .CheckProperty( c => c.AuthorEmail, "vinay@simplyvinay.com" )
                .CheckProperty( c => c.AuthorIP, "127.0.0.1" )
                .CheckProperty( c => c.AuthorName, "vinay" )
                .CheckProperty( c => c.AuthorUrl, "www.simplyvinay.com" )
                .CheckProperty( c => c.Body, "comment" )
                .CheckProperty( c => c.AddedDate, DateTime.Today )
                .CheckReference( c => c.Post,
                                new Post
                                    {
                                        AddedBy = "vinay",
                                        PostTitle = "title",
                                        PostText = "text",
                                        ExcerptText = "text",
                                        PostSlug = "slug",
                                        PublishDate = DateTime.Today
                                    } )
                .VerifyTheMappings();
        }
    }
}

That's it for now. In my next post, I’ll discuss about the repository and the unit of work implementations. Any sort of feedback will be appreciated.

He goes like this for me saying that I am the domain expert for the sample application I was building.

My main feedback would be that a DDD example done without an external domain expert probably isn't a good idea. A few of us have tried this over the years and decided it wasn't a great idea, I'd at the least indicate your using *some* of the patterns from DDD but not others (including the working with domain experts) and that this isn't necessarily the sort of problem that suits a full DDD approach

And for the application itself…

I don't think it suits full DDD no, because you need domain experts and a complex enough problem domain to justify it. Doesn't mean you shouldn't do an example of the patterns and continue on as you are. If you learn from it and teach others then superb, however I'd just make sure to mention that DDD is about more than the patterns (repository/aggregate/value object/specification/service) and related technologies/practices (ORMs/TDD/POCO) that most people use.

Even I had a few doubts about the application when I had planned for it, so from my next post ( for the series ), I wont be talking about DDD anymore. So what changes? Nothing really, from the project structure to the tools, nothing changes. Having a domain layer doesn't mean that the application uses DDD and segregating the project structure as I have gives a clear understanding with separation of concerns. Although I might have have to change a few things that I had thought of using like the Aggregates and a few. I don’t want that sort of complexity as of now.

And about DDD, I really like the way it helps you build a software. I have barely touched the surface of it and will surely blog about it in the future.

P.S. The sample application will no longer be called as DDDBlog. This site is running on a custom blog I wrote which I had named MPS ( MyPersonalSite ), so may be I will call the sample application as MPBlog.

Layer SuperType: The Entity Base Class

Before we start of creating the domain objects, lets first create the base entity object. As discussed before, an entity is something that has an identity. This would be our layer supertype because this class will be inherited by all our domain objects that needs to have an identity.

namespace DDDBlog.Infrastructure.BaseClasses
{
    using System;
 
    public interface IEntity
    {
        int Key { get; }
    }
 
    public abstract class Entity : IEntity
    {
        private int key;
        public int Key
        {
            get { return key; }
        }
 
        protected Entity()
        {
        }
 
        protected Entity(int key)
        {
            this.key = key;
        }
 
        public bool Equals( Entity other )
        {
            return Equals( this, other );
        }
 
        public override bool Equals( object obj )
        {
            return Equals( this, obj as Entity );
        }
 
        public static bool Equals( Entity obj1, Entity obj2 )
        {
            if ( Object.Equals( obj1, null ) || Object.Equals( obj2, null ) ||
                obj1.GetType() != obj2.GetType() )
                return false;
 
            if ( ReferenceEquals( obj1, obj2 ) ) return true;
 
            return obj1.Key == obj2.Key;
        }
 
        public override int GetHashCode()
        {
            return Key.GetHashCode();;
        }
    }
}

The Entity base class is defined in the Infrastructure layer as the definition of entity is not part of the domain itself but it will be used by the domain. As you can see the Entity class has a key property which would be used as an identity. Also I am taking the key to be integer for simplicity. I have also implemented the equality comparison on the entity object. This is used to compare the entities.

Entity Tests

Now lets see some tests on the Entity class. A thing to remember is that in TDD, we would have to write the tests firsts and then come at the object.

namespace DDDBlog.Tests.Infrastructure.Tests
{
    using DDDBlog.Infrastructure.BaseClasses;
    using Xunit;
 
    public class FakeEntity : Entity
    {
        public FakeEntity()
            : base( 0 )
        {
        }
 
        public FakeEntity( int key )
            : base( key )
        {
        }
    }
 
    public class EntityTests
    {
        [Fact]
        public void Can_Create_An_Entity()
        {
            var entity = new FakeEntity();
            Assert.NotNull( entity );
        }
 
  [Fact]
        public void Newly_Created_Entity_Id_Should_Be_Zero()
        {
            var entity = new FakeEntity();
            Assert.Equal( entity.Key, 0 );
        }
 
        [Fact]
        public void Two_Entities_With_Same_Key_Should_Be_Equal()
        {
            var entity1 = new FakeEntity( 21 );
            var entity2 = new FakeEntity( 21 );
 
            Assert.Equal( entity1, entity2 );
            Assert.Equal( entity1.GetHashCode(), entity2.GetHashCode() );
        }
 
        [Fact]
        public void Two_Entities_With_Diffrent_Key_Should_Not_Be_Equal()
        {
            var entity1 = new FakeEntity( 21 );
            var entity2 = new FakeEntity( 3 );
 
            Assert.NotEqual( entity1, entity2 );
            Assert.NotEqual( entity1.GetHashCode(), entity2.GetHashCode() );
        }
 
 
        [Fact]
        public void Reference_To_Same_Entity_Should_Be_Equal()
        {
            var entity1 = new FakeEntity( 21 );
            var entity2 = entity1;
 
            Assert.Equal( entity1, entity2 );
            Assert.Equal( entity1.GetHashCode(), entity2.GetHashCode() );
        }
    }
}

AggregateRoot And IRepository<T>

Along with the Entity base class, we also need a repository base, and a way to mark an entity as an aggregate root. These are shown in the following snippets

namespace DDDBlog.Infrastructure.BaseClasses
{
    public interface IAggregateRoot : IEntity { }
}

namespace DDDBlog.Infrastructure.Repository
{
    using System.Linq;
    using BaseClasses;
 
    public interface IRepository<T> where T : IAggregateRoot
    {
        T FindBy( int key );
        IQueryable<T> FindAll();
        void Save( T entity );
        void Delete( T entity );
    }
}

As you can see our Aggregate root base is just an interface that inherits from IEntity. This is done because a repository is ( should be ) provided only on the Aggregate root. You can read a bit on Aggregates and Repositories here.

Now that our base classes are ready, we can look at the domain objects of our sample application, which I will be talking about in the next post.

You must know that, I am by no means an expert in DDD, TDD. The code shown above might be wrong as I am just stepping into this part of the world. Please leave a comment/ suggestion if you find something to be wrong or if it could be done better.

Setting up the project

Lets create the project structure as shown below.

DDDBlog.Domain : Domain layer is where the Plain-Old CLR Objects reside. These POCOs are entities that form the domain objects for our project. This layer would also contain the repository interface declarations for the domain objects. From a DDD perspective, the Domain layer should be unaware of persistence ( Persistence Ignorance ), so this layer will not have references to the Persistence layer

DDDBlog.Infrastructure : Infrastructure layer provides the bridging for other layers involved in the application. This layer will be used by all other layers. This layer would contain all the base classes required for all other projects. This layer would also define the top level repository interface. I am not sure where the mapping files should fall under this layer or the persistence layer, but for now I think I will go with this layer.

DDDBlog.Persistence :  This layer would contain the actual data access code. Here I will write the actual implementations for the repositories.

DDDBlog.Tests : This layer consists all the tests for all the layers. Its not necessary for us to have single test layer. We can add individual test layer for each of the layers in our application. I however am going with a single test layer.

DDDBlog.Web : This is the web presentation layer for our application.

Tools and libraries used

ASP.NET MVC – Used for the presentation layer. I had thoughts of using Monorail, but preferred ASP.NET MVC as it has come a long way from the CTP’s and I think its pretty good as of now.

NHibernate and FluentNHibernate – These are used for persistence and for the mappings.

StructureMap – This is used for Dependency Injection.

xUnit.Net – This is used for unity testing.

MoQ – This is used for mocking.

In this post we have seen how to layer our application and the tools/libraries that’s needed for our project. In my next post we’ll start coding the base classes for our application.

Test Driven Development

TDD could be told as an approach in development, where we are writing tests to know the area for which we are building the software. Tests written during the development phase helps you in understanding the domain, and, after development tests helps us document that system. Following are a few things about TDD that I have understood

The Steps

1) We write a failing test. We have to identity whether the test is testing what is intended in this step.
2) We make sure the test written in step 1 passes.
3) We refactor the code written in step 2.

We can also segregate a single test into 3 sections viz. Arrange – Where we setup everything that is there to test, Act – We do everything there is to do with the test, Assert – We check our assertions to be true or not.

But its hard to test

There are certain areas that are hard to test, like UI ( Its all the more reason to split the UI aspects from the domain model ). Then there is the database which makes it even harder to test. Why? because working with actual db is cumbersome, we have to maintain the state of database for every run of the test. This could be done for integration test, but while in development stages, stubs or mocks could be used, and lastly there is the code of the tests themselves which we’ll have to maintain, but that should be ok, because the tests helps a lot in doing maintenance work.

Stubs and Mocks

There will certain areas in our development which when tested might be too slow or difficult to setup for example the UI or the database operation. To overcome these difficulties we can use stubs or mocks.

A stub is a light weight implementation of a real object. It is a way to setup the expected values that can be used within the test. In tests stubs we create a class that impersonates the actual class that we have to test. For example if we are to test a class that does database operations, we create a stub class that is free of the database and use this stub class in our tests. The thing to note here is that we are testing the database operation methods and not the actual database call and also we provide the input and the output via the stubs. A mock is also an implementation of a real object, but unlike stubs we can set our expectations in mocks on how it should be used and it also provides self validations on the expected results. Mocks are usually created frameworks.

You can read about the differences between mocks and stubs here

I will be writing more on TDD as I dwell more into the development of the sample application.

Aggregates and Aggregate Root

In a software there can invariably be many objects, and some of these objects are bound to be related to each other in some way. These objects that are related to each other are known as aggregates and an aggregate root is the object that holds them together. Aggregate root is always an entity. Say for example in a blog application a comment would be related to a post. So post and comments become an aggregate and post becomes the aggregate root as there cant be any comments without a post.

Aggregates are to be considered as one unit with regard to any data manipulation and these aggregates can be accessed from outside only through their aggregate root. This mechanism of accessing the objects only by the root helps in maintain data integrity as individual objects can not be changed directly.

Factories

When we are to create an aggregate or an entity, it might become too complex for us to create it in the constructor of the root entity. This is where the factory fits in. The role of the factory is to create an object. These factories are helpful when we are creating an aggregate because when the root is created, all the associated aggregates under the root is also created for us.

The process of object creation by a factory needs to be atomic. This is required because we don’t want to have an aggregate root created without creating the the associated aggregates which might leave the system in a unstable state.

You can read about the factory pattern from my earlier posts here and here.

Repositories

In any application, domain objects will need other objects for their operation. So these domain objects could be made to hold references to the other needed objects. If we are to give the  domain objects this behavior of maintaining references, then they become tightly coupled as they are holding on to all the references they need at any given time.

This could be avoided by the using repositories. Repositories are used to maintain the references of objects. Using repositories the domain objects are not involved in maintaining the references to the needed object, instead they can get it from the repository.

Repositories are just a storage place where we can store the data and retrieve it later. These repositories are based on strategy, meaning,  based on different strategies it may use different storage locations for different type of objects.

Next Steps

What I have covered in this and my previous post is just the starting point of DDD. There are still many factors into DDD, which probably I will be writing about as I build the application.

In my next post I will be writing about the project structure, why the project is split as it is, and what is the role of each layer.

DDD could be called as a methodology or a set of patterns which help us in developing a software pertaining to the domain. Here what domain means, is the actual system for which we are building the software. DDD is not breaking away from the core Object Oriented design principles, but to utilize them in the right way. There are many aspects in DDD which we need to consider when building an application. Following are the aspects and their brief explanations from what I have understood.

The Ubiquitous Language ( UL )

Developers when building a software tend to wholly dwell into the technical aspects of the the application unlike the domain experts who have an extensive knowledge of the problem domain rather than the technical solution for it. When a domain expert is sharing his expertise, he will using a lot of terms that may not be understood by the development team, thus brining in a communication gap between the two. 

Ubiquitous language in DDD addresses this communication gap between the developers and the business experts. The function of the UL is to connect all parts of the design which would have been led by the domain experts and developers need to follow this. The key point in UL is to identify the the concepts which defines the domain and come up with common terms for those.

Layered Architecture

When we develop a software in the OO way, a lot of UI and data specific code is mixed with the domain objects. The problem with this is a change in the UI or the data specific code might change the domain behavior and tracking these changes becomes difficult because to arrive at the domain behavior we’ll have to check the UI/data components which changed the behavior in the first place.

The solution for this is to segregate the software into layers such that the layers are loosely coupled and one layer being dependent only on the layers below it. The main criteria in the layering is to free up the domain objects from the UI/data specific logic.

I will talk about the different layers in a future post where I’ll come up with the initial project structure for the blog application.

Entities and Value Objects

Entities and Value Objects form the underlying principles in DDD. Entities are objects which have an identity and this identity is maintained throughout the lifetime of the application. The identity can be represented  differently in different applications, for example an store application can have an Customer entity which can be identified from the CustomerID.

Value Objects are objects that have no identity, meaning that we are representing an object by its attributes alone. Usually Value Objects acts as a part of an entity, for example the Customer entity can have an Address Value object which in itself cannot be identified other than belonging to a customer.

Services

When developing a software there are certain behavior which might not fit into entities or value objects, meaning if we add these behavior into the objects then they might give a different meaning to the object, which was not intended. But in OO languages we would need an object to represent this functionality, These objects are declared as services. For example in a store application shipping a product to a customer can be declared as a service.

Services are interfaces which are used in performing some operations on the objects ( entities / value objects ). These operations are the ones that doesn't fit in the objects.

This is the the end of Part I. I will continue with the basics of DDD in my next post.

So I am going to start a “Learn as you build” series in which I build a blog engine using these technologies ( or methodologies ). This is not a full fledged blog engine mind you. This is a process of learning new things and blog engine is just right to start of with ( along the lines from this post). If you are looking for a full featured blog engine, you can have a look at BlogEngine.NET or DasBlog or SubText and many more I guess.

Along with these things I would also want to explore NHibernate which is an ORM ( another TLA!!! ) and MoQ ( a mocking framework ). Well I think I am getting into a lot of things, probably more than I can handle, but lets see where these things lead me.

I would appreciate any sort of suggestions that might help me in diving into these things.

More blogs to follow on these lines.

Structural Patterns

1. Decorator Pattern
2. Proxy Pattern
3. Bridge Pattern
4. Composite Pattern
5. Flyweight Pattern
6. Adapter Pattern
7. Façade Pattern

Creational Patterns

1. Prototype Pattern
2. Factory Method Pattern
3. Singleton Pattern
4. Abstract Factory Pattern
5. Builder Pattern

Behavioral Patterns

1. Strategy Pattern
2. State Pattern
3. Template Method Pattern
4. Chain of Responsibility Pattern
5. Command Pattern
6. Iterator Pattern
7. Mediator Pattern
8. Observer Pattern
9. Visitor Pattern
10. Interpreter Pattern
11. Memento Pattern

These writings doesn't dwell into the patterns deeply and are written just to give an idea of what they are ( for dummies remember ). The real challenge is identifying the problem rather than the pattern implementations. Although there are as many patterns as discussed, it is not necessary to implement all of them in any project. We’ll have to contemplate on the problem and see what fits in to our project.

Its was fun going through all off these patterns and hope you readers have enjoyed and learnt a few things from it.

P.S You can find the UML class diagrams to all of these patterns from dofactory site

1. Strategy Pattern
2. State Pattern
3. Template Method Pattern
4. Chain of Responsibility Pattern
5. Command Pattern
6. Iterator Pattern
7. Mediator Pattern
8. Observer Pattern
9. Visitor Pattern
10. Interpreter Pattern

You can read about the Structural patterns here.
You can read about the Creational patterns here.

The Memento

The memento pattern deals with capturing an object’s internal state and saving it externally so that the internal state of that object can be restored later. This pattern is usually used in computer games where the state of the game can be saved, and can be started from the same point. The following example illustrates the use of memento pattern.

The components that make up the memento pattern are the Originator, for which the state has to be saved, the Caretaker which is a class that holds the mementos and the Memento which holds the state of the originator.

namespace PatternsConsole
{
    class MementoPatter
    {
        // Originator
        [Serializable]
        class PersonInfo
        {
            public string Name { get; set; }
            public float Salary { get; set; }
 
            public Memento SetMemento()
            {
                var memento = new Memento();
                return memento.Save( this );
            }
 
            public void GetMemento( Memento memento )
            {
                var info = memento.Restore() as PersonInfo;
                if ( info != null )
                {
                    Name = info.Name;
                    Salary = info.Salary;
                }
            }
        }
 
        // Memento
        [Serializable]
        class Memento
        {
            readonly MemoryStream stream = new MemoryStream();
            readonly BinaryFormatter formatter = new BinaryFormatter();
 
            public Memento Save( object obj )
            {
                formatter.Serialize( stream, obj );
                return this;
            }
 
            public object Restore()
            {
                stream.Seek( 0, SeekOrigin.Begin );
                var obj = formatter.Deserialize( stream );
                stream.Close();
                return obj;
            }
        }
 
        // CareTaker
        class CareTaker
        {
            public Memento Memento { get; set; }
        }
 
        private static void Main()
        {
            var personInfo = new PersonInfo
                                 {
                                     Name = "Person1", Salary = 5000
                                 };
 
            // Store internal state
            var careTaker = new CareTaker
                        {
                            Memento = personInfo.SetMemento()
                        };
 
            Console.WriteLine( "Saved State : \nName = {0}, Salary = {1}",
                personInfo.Name, personInfo.Salary );
 
            // Change originator
            personInfo.Name = "Person2";
            personInfo.Salary = 10000;
 
            Console.WriteLine( "Changed Sate : \nName = {0}, Salary = {1}",
                personInfo.Name, personInfo.Salary );
 
            // Restore saved state
            personInfo.GetMemento( careTaker.Memento );
 
            Console.WriteLine( "Restored State : \nName = {0}, Salary = {1}",
                personInfo.Name, personInfo.Salary );
 
            // Output :
            // Saved State :
            // Name = Person1, Salary = 5000
            // Changed Sate :
            // Name = Person2, Salary = 10000
            // Restored State :
            // Name = Person1, Salary = 5000
 
            Console.ReadLine();
        }
    }
}

The memento pattern can be used when we need to save an object’s state and retrieve it later or when we don't want to expose an objects state directly.

1. Strategy Pattern
2. State Pattern
3. Template Method Pattern
4. Chain of Responsibility Pattern
5. Command Pattern
6. Iterator Pattern
7. Mediator Pattern
8. Observer Pattern
9. Visitor Pattern

You can read about the Structural patterns here.
You can read about the Creational patterns here.

The Interpreter

The interpreter pattern deals with interpretation of instructions defined for some specific purpose. The instructions are given as notations which are precise and can be defined in terms of grammar. For the sake of example, the notation in the following example is taken to be “PCCCCPC”. We will have to parse this expression and interpret it.

The components that make up an interpreter pattern are Context which contains information that is used by the interpreter and Element ( Term ) which provides an interface for the structure and the default operation for the interpreter.

Parsing

The interpreter pattern itself does not specify how the objects are to be built. For this purpose parsing is used, in which the the input is matched against a grammar to create the object structure. Once this is created the objects can passed to an interpreter to do its work.

namespace PatternsConsole
{
    class InterpreterPattern
    {
        //Context
        class Context
        {
            public string Input { get; set; }
 
            public Context( string input )
            {
                Input = input;
            }
        }
 
        // Term ( Includes a Parse method to parse the input )
        abstract class Element
        {
            public abstract char GetElement();
            public abstract void Interpret();
 
            public void Parse( Context context )
            {
                if ( context.Input.Length == 0 )
                {
                    return;
                }
 
                foreach (var character in context.Input)
                {
                    if ( character.CompareTo( GetElement() ) ==0 )
                    {
                        Interpret();
                    }
                }
            }
        }
 
        class Producer : Element
        {
            public override char GetElement()
            {
                return 'P';
            }
 
            public override void Interpret()
            {
                Console.WriteLine( "Interpreted Producer" );
            }
        }
 
        class Consumer : Element
        {
            public override char GetElement()
            {
                return 'C';
            }
 
            public override void Interpret()
            {
                Console.WriteLine( "Interpreted Consumer" );
            }
        }
 
        private static void Main()
        {
            var expression = "PCCCCPC";
            var context = new Context( expression );
 
            var tree = new List<Element>
                           {
                               new Producer(), new Consumer()
                           };
 
            Console.WriteLine( "Exression : {0}\n", expression );
 
            foreach ( var element in tree )
            {
                element.Parse( context );
            }
 
            // Output:
            // Exression : PCCCCPC
            //
            // Interpreted Producer
            // Interpreted Producer
            // Interpreted Consumer
            // Interpreted Consumer
            // Interpreted Consumer
            // Interpreted Consumer
            // Interpreted Consumer
 
            Console.Read();
        }
    }
}

This pattern has performance issues and is rarely used. We can use the Interpreter pattern when we have a grammar to be interpreted and the grammar is fairly small and efficiency is not critical.

1. Strategy Pattern
2. State Pattern
3. Template Method Pattern
4. Chain of Responsibility Pattern
5. Command Pattern
6. Iterator Pattern
7. Mediator Pattern
8. Observer Pattern

You can read about the Structural patterns here.
You can read about the Creational patterns here.

The Visitor

Suppose you need to add a new method to a structure of classes, you might end up damaging the design. This is where the visitor pattern comes into play. The visitor pattern deals with performing new operations on all elements of an existing hierarchy of classes without altering the the classes themselves. 

The visitor pattern is mainly made up of 2 components, the classes that make up the hierarchy and the methods that are applied to these classes. These methods are called as visitors. In the following example there is one visitor viz. SalaryVisitor which increments a persons salary.

The following example is based on the example shown in the Dofactory site

namespace PatternsConsole
{
    class VisitorPattern
    {
        // Visitor
        public abstract class Visitor
        {
            public void ReflectiveVisit( Element element )
            {
                var types = new[] { element.GetType() };
                var methodInfo = GetType().GetMethod( "Visit", types );
                if ( methodInfo != null )
                {
                    methodInfo.Invoke( this, new object[] { element } );
                }
            }
        }
 
        // Element
        public abstract class Element
        {
            public abstract void Accept( Visitor visitor );
        }
 
        // ConcreteElement
        class Person : Element
        {
            public string Name { get; set; }
            public string Designation { get; set; }
            public double Salary { get; set; }
 
            public Person( string name, string designation, double salary )
            {
                Name = name;
                Designation = designation;
                Salary = salary;
            }
 
            public override void Accept( Visitor visitor )
            {
                visitor.ReflectiveVisit( this );
            }
        }
 
        // ElementType
        class Developer : Person
        {
            public Developer( string name, double salary ) :
                base( name, "Developer", salary )
            {
            }
        }
 
        // ElementType
        class Tester : Person
        {
            public Tester( string name, double salary ) :
                base( name, "Tester", salary )
            {
            }
        }
 
        // ConcreteVisitor
        class SalaryVisitor : Visitor
        {
            public void Visit( Developer developer )
            {
                VisitMethod( developer );
            }
 
            public void Visit( Tester tester )
            {
                VisitMethod( tester );
            }
 
            private static void VisitMethod( Element element )
            {
                var employee = element as Person;
 
                if ( employee != null )
                {
                    employee.Salary *= 1.50;
                    Console.WriteLine( "{0} {1}'s new income: {2:C}",
                                       employee.GetType().Name, employee.Name,
                                       employee.Salary );
                }
            }
 
 
        }
 
 
        private static void Main()
        {
            // ObjectStructure
            var people = new List<Person>();
 
            var developer = new Developer( "Foo", 1000 );
            var tester = new Tester( "Bar", 1500 );
 
            people.Add( developer );
            people.Add( tester );
 
            foreach ( var person in people )
            {
                person.Accept( new SalaryVisitor() );
            }
 
            //Output: Developer Foo's new income: $1,500.00
            //        Tester Bar's new income: $2,250.00
 
            Console.ReadLine();
        }
    }
}

The visitor pattern provides number of ways to modify the behavior of a hierarchy of classes without modifying the classes. We can use the visitor pattern when we have a hierarchy that is sealed or when there are many operations to perform on it or when we need the flexibility of defining new operations.

In my next post I will be writing about the Interpreter pattern.

1. Strategy Pattern
2. State Pattern
3. Template Method Pattern
4. Chain of Responsibility Pattern
5. Command Pattern
6. Iterator Pattern
7. Mediator Pattern

You can read about the Structural patterns from here.
You can read about the Creational patterns from here.

The Observer pattern deals with providing a relation between objects such that when one objects changes its state, then all the other objects that have a relation to it are notified of the change. This could be achieved by using a single publisher of the state of object and many subscribers who may want the notification for the changed state.

The Observer is usually composed of 2 class viz. a Subject whose state may change periodically and the Observer itself who maybe notified of the change, if they wish to receive the state change information.

The following example is based on the example from Dofactory website

    1 namespace PatternsConsole
    2 {
    3     class ObserverPattern
    4     {
    5         public delegate void ChangeEventHandler<TArg1, TArg2>( TArg1 sender, TArg2 eventArgs );
    6 
    7         public class ChangeEventArgs : EventArgs
    8         {
    9             public string Title { get; set; }
   10             public string Name { get; set; }
   11 
   12             public ChangeEventArgs( string name, string title )
   13             {
   14                 Name = name;
   15                 Title = title;
   16             }
   17 
   18         }
   19 
   20         // Subject
   21         class Blog
   22         {
   23             public string Name { get; private set; }
   24             protected string title;
   25 
   26             // Constructor
   27             public Blog( string name, string title )
   28             {
   29                 Name = name;
   30                 this.title = title;
   31             }
   32 
   33             public event ChangeEventHandler<Blog, ChangeEventArgs> Change;
   34 
   35             public virtual void OnChange( ChangeEventArgs e )
   36             {
   37                 if ( Change != null )
   38                 {
   39                     Change( this, e );
   40                 }
   41             }
   42 
   43             public void Attach( IObserver observer )
   44             {
   45                 Change += observer.Update;
   46             }
   47 
   48             public string Title
   49             {
   50                 set
   51                 {
   52                     title = value;
   53                     OnChange( new ChangeEventArgs( Name, title ) );
   54                     Console.WriteLine( "" );
   55                 }
   56             }
   57         }
   58 
   59         // Observer
   60         interface IObserver
   61         {
   62             void Update( Blog sender, ChangeEventArgs e );
   63         }
   64 
   65         // ConcreteObserver
   66         class Observer : IObserver
   67         {
   68             public string Name { get; private set; }
   69 
   70             public Observer( string name )
   71             {
   72                 Name = name;
   73             }
   74 
   75             public void Update( Blog sender, ChangeEventArgs e )
   76             {
   77                 Console.WriteLine( "Notified {0} of {1}'s " + "post : {2}", Name, e.Name, e.Title );
   78             }
   79         }
   80 
   81         static void Main()
   82         {
   83             var rob = new Blog( "Rob Conery", "Weke Road" );
   84             rob.Attach( new Observer( "Vinay" ) );
   85 
   86             rob.Title = "Subsonic 3";
   87             rob.Title = "Storefront Finis";
   88             rob.Title = "Oxite Refactor";
   89 
   90             //Output : 
   91             // Notified Vinay of Rob Conery's post : Subsonic 3
   92             //
   93             // Notified Vinay of Rob Conery's post : Storefront Finis
   94             //
   95             // Notified Vinay of Rob Conery's post : Oxite Refactor
   96 
   97             Console.ReadLine();
   98         }
   99     }
  100 }

We can use the observer pattern when changes in one object needs to be propagated to other objects or when the object sending the changes does not need to know about the receivers.

In my next post I will be writing about the Visitor Pattern

1. Strategy Pattern
2. State Pattern
3. Template Method Pattern
4. Chain of Responsibility Pattern
5. Command Pattern
6. Iterator Pattern

You can read about the Structural patterns from here.
You can read about the Creational patterns from here.

The Mediator patterns deals with providing a way for objects to communicate with each other without knowing each others identity. The participants involved in this pattern are a Mediator and Colleague. A concrete colleague is used to communicate with other colleagues through its mediator.

    1 namespace PatternsConsole
    2 {
    3     class MediatorPattern
    4     {
    5         public delegate void Callback( string message, string from );
    6 
    7         class Mediator
    8         {
    9             Callback respond;
   10 
   11             public void Register( Callback method )
   12             {
   13                 respond += method;
   14             }
   15 
   16             // Send is implemented as a broadcast
   17             public void Send( string message, string from )
   18             {
   19                 respond( message, from );
   20                 Console.WriteLine();
   21             }
   22         }
   23 
   24         class FooColleague
   25         {
   26             Mediator mediator;
   27             protected string name;
   28 
   29             public FooColleague( Mediator mediator, string name )
   30             {
   31                 this.mediator = mediator;
   32                 this.name = name;
   33                 mediator.Register( Receive );
   34             }
   35 
   36             public virtual void Receive( string message, string from )
   37             {
   38                 if ( !string.Equals( from, name ) )
   39                     Console.WriteLine( name + " received from " + from + ": " + message );
   40             }
   41 
   42             public void Send( string message )
   43             {
   44                 Console.WriteLine( "Send (From " + name + "): ");
   45                 mediator.Send( message, name );
   46             }
   47 
   48         }
   49 
   50         class BarColleague : FooColleague
   51         {
   52             public BarColleague( Mediator mediator, string name )
   53                 : base( mediator, name ) { }
   54 
   55             public override void Receive( string message, string from )
   56             {
   57                 if ( !string.Equals( from, name ) )
   58                     Console.WriteLine( name + " received from " + from + ": " + message );
   59             }
   60         }
   61 
   62         static void Main()
   63         {
   64             var mediator = new Mediator();
   65 
   66             var foo = new FooColleague( mediator, "Foo" );
   67             var bar = new BarColleague( mediator, "Bar" );
   68 
   69             foo.Send( "Hi Bar! This is a greeting through the mediator" );
   70             bar.Send( "Hi Foo! Really!!" );
   71 
   72             // Output :
   73             // Send (From Foo):
   74             // Bar received from Foo: Hi Bar! This is a greeting through the mediator
   75 
   76             // Send (From Bar):
   77             // Foo received from Bar: Hi Foo! Really!!
   78 
   79             Console.ReadLine();
   80         }
   81     }
   82 }

We can use the mediator pattern when we have objects are communicating in a complex way or when we have to protect the identities of objects who are communicating.

In my next post I will be writing about the Observer Pattern.

1. Strategy Pattern
2. State Pattern
3. Template Method Pattern
4. Chain of Responsibility Pattern
5. Command Pattern

You can read about the Structural patterns from here.
You can read about the Creational patterns from here.

The Iterator patterns deals with providing an easy way to access elements of a collection sequentially. To implement an iterator in C#, we can implement either IEnumerator or the IEnumerable interfaces.  IEnumerator interface has 2 methods GetEnumerator and Reset which we would have to implement and an Current object which is used to maintain the position. The easier way of doing it is to implement the IEnumerable interface and implement the GetEnumerator method for it. In the following example I am using the yield return statement in the GetEnumerator method which saves us from maintaining the state.

    1 namespace PatternsConsole
    2 {
    3     class IteratorPattern
    4     {
    5         class Collection<T> : IEnumerable<T>
    6         {
    7             private readonly List<T> items = new List<T>();
    8 
    9             public void Add( T t )
   10             {
   11                 items.Add( t );
   12             }
   13 
   14             public IEnumerator<T> GetEnumerator()
   15             {
   16                 for ( int i = 0; i < Count; i++ )
   17                 {
   18                     yield return items[i];
   19                 }
   20             }
   21 
   22             public int Count
   23             {
   24                 get { return items.Count; }
   25             }
   26 
   27             IEnumerator IEnumerable.GetEnumerator()
   28             {
   29                 return GetEnumerator();
   30             }
   31         }
   32 
   33         class Person
   34         {
   35             public string Name { get; private set; }
   36 
   37             public Person( string name )
   38             {
   39                 Name = name;
   40             }
   41         }
   42 
   43         private static void Main()
   44         {
   45             var people = new Collection<Person>
   46                              {
   47                                  new Person("Person 1"),
   48                                  new Person("Person 2"),
   49                                  new Person("Person 3"),
   50                                  new Person("Person 4"),
   51                                  new Person("Person 5")
   52                              };
   53 
   54             foreach ( var person in people )
   55             {
   56                 Console.WriteLine( person.Name );
   57             }
   58 
   59             // Output :
   60             // Person 1
   61             // Person 2
   62             // Person 3
   63             // Person 4
   64             // Person 5
   65 
   66             Console.ReadLine();
   67         } 
   68     }
   69 }

We can implement our iterator when we want iterations over a collection or we have many ways of traversing it or when there are many collections for traversing.

In my next post I will be writing about the Mediator Pattern.

1. Strategy Pattern
2. State Pattern
3. Template Method Pattern
4. Chain of Responsibility Pattern

You can read about the Structural patterns from here.
You can read about the Creational patterns from here.

The Command pattern deals with segregation of the client that requested an operation and the object that can perform that operation. The command pattern can support sending requests to different receivers, queuing of requests, redo and undo functionality.

    1 namespace PatternsConsole
    2 {
    3     public class CommandPattern
    4     {
    5         // Command
    6         interface ICommand
    7         {
    8             void Execute();
    9         }
   10 
   11         // ConcreteCommand
   12         class AddCommand : ICommand
   13         {
   14             public Item Itm { get; set; }
   15             public Category Cat { get; set; }
   16 
   17             public void Execute()
   18             {
   19                 Itm.Add( Cat );
   20                 Cat.Add( Itm );
   21             }
   22         }
   23 
   24         // ConcreteCommand
   25         class DeleteCommand : ICommand
   26         {
   27             public Item Itm { get; set; }
   28             public Category Cat { get; set; }
   29 
   30             public void Execute()
   31             {
   32                 Itm.Delete( Cat );
   33                 Cat.Delete( Itm );
   34             }
   35         }
   36 
   37         // Invoker
   38         class ItemManager
   39         {
   40             public ICommand Command { set; get; }
   41 
   42             public void Process()
   43             {
   44                 Command.Execute();
   45             }
   46         }
   47 
   48         // Receiver
   49         class Item
   50         {
   51 
   52             private IDictionary<string, Category> categories;
   53 
   54             public string Desc { get; set; }
   55 
   56             public Item( string itemName )
   57             {
   58                 Desc = itemName;
   59                 categories = new Dictionary<string, Category>();
   60             }
   61 
   62             public void Add( Category cat )
   63             {
   64                 categories.Add( cat.Desc, cat );
   65             }
   66 
   67             public void Delete( Category cat )
   68             {
   69                 categories.Remove( cat.Desc );
   70             }
   71 
   72         }
   73 
   74         // Receiver
   75         class Category
   76         {
   77 
   78             private IDictionary<string, Item> items;
   79 
   80             public string Desc { get; set; }
   81 
   82             public Category( string catName )
   83             {
   84                 Desc = catName;
   85                 items = new Dictionary<string, Item>();
   86             }
   87 
   88             public void Add( Item item )
   89             {
   90                 items.Add( item.Desc, item );
   91                 Console.WriteLine( "Item '" + item.Desc + "' has been added to the '"
   92                     + Desc + "' Category " );
   93             }
   94 
   95             public void Delete( Item item )
   96             {
   97                 items.Remove( item.Desc );
   98                 Console.WriteLine( "Item '" + item.Desc
   99                     + "' has been deleted from the '" + Desc + "' Category " );
  100             }
  101         }
  102 
  103         public static void Main()
  104         {
  105             // Create Receiver objects
  106             Item DVD = new Item( "The Fountain" );
  107             Category catDVD = new Category( "DVD" );
  108 
  109             // create the command object
  110             ICommand command = new AddCommand { Itm = DVD, Cat = catDVD };
  111 
  112             // create the invoker
  113             ItemManager manager = new ItemManager { Command = command };
  114             manager.Process();
  115 
  116             // Add an item to the CD category
  117             DVD = new Item( "The Wrestler" );
  118             catDVD = new Category( "DVD" );
  119             command = new AddCommand { Itm = DVD, Cat = catDVD };
  120             manager.Command = command;
  121             manager.Process();
  122 
  123             // Add an item to the Old Releases category
  124             DVD = new Item( "Pi" );
  125             catDVD = new Category( "Old Releases" );
  126             command = new AddCommand { Itm = DVD, Cat = catDVD };
  127             manager.Command = command;
  128             manager.Process();
  129 
  130             // Delete an item from the Old Releases category
  131             command = new DeleteCommand { Itm = DVD, Cat = catDVD };
  132             manager.Command = command;
  133             manager.Process();
  134 
  135             // Output:
  136             // Item 'The Fountain' has been added to the 'DVD' Category
  137             // Item 'The Wrestler' has been added to the 'DVD' Category
  138             // Item 'Pi' has been added to the 'Old Releases' Category
  139             // Item 'Pi' has been deleted from the 'Old Releases' Category
  140 
  141             Console.ReadLine();
  142         }
  143     }
  144 }

We can use the command pattern when we have different receivers and handle each in a different way or we want to specify and execute commands at different times or when we want to support undo functionality.

In my next post I will be writing about the Iterator pattern.

1. Strategy Pattern
2. State Pattern
3. Template Method Pattern

You can read about the Structural patterns from here.
You can read about the Creational patterns from here.

The Chain of Responsibility pattern deals with a list of Handler objects that limits based on the requests that they can deal with. If one object can not handle a request, then the request is passed to the next object in the chain which means by the end of the chain there can be an expected behavior or an exception. 

The following example is based on the example provided in the DoFactory website

    1 namespace PatternsConsole
    2 {
    3     class ChainOfResponsibilityPattern
    4     {
    5         // Delegate for withdrawal requests
    6         public delegate void WithdrawHandler<T, E>( T sender, E eventArgs );
    7 
    8         public class WithdrawArgs : EventArgs
    9         {
   10             public double Amount { get; set; }
   11             public int AccountNumber { get; set; }
   12         }
   13 
   14         // "Handler"
   15         abstract class Approver
   16         {
   17             public event WithdrawHandler<Approver, WithdrawArgs> Withdraw;
   18             public Approver Successor { protected get; set; }
   19 
   20             // Invoing the event
   21             public virtual void OnWithdraw( WithdrawArgs e )
   22             {
   23                 if ( Withdraw != null )
   24                 {
   25                     Withdraw( this, e );
   26                 }
   27             }
   28 
   29             public void ProcessRequest( WithDrawal withDrawal )
   30             {
   31                 OnWithdraw( new WithdrawArgs
   32                                 {
   33                                     AccountNumber = withDrawal.AccountNumber,
   34                                     Amount = withDrawal.Amount
   35                                 } );
   36             }
   37         }
   38 
   39         // "ConcreteHandler"
   40         class Clerk : Approver
   41         {
   42             public Clerk()
   43             {
   44                 // Hook up delegate to event
   45                 Withdraw += ProcessByClerk;
   46             }
   47 
   48             public void ProcessByClerk( Approver approver, WithdrawArgs e )
   49             {
   50                 if ( e.Amount < 10000 )
   51                 {
   52                     Console.WriteLine( "{0} approved withdrawal for account : {1}",
   53                         GetType().Name, e.AccountNumber );
   54                 }
   55                 else if ( Successor != null )
   56                 {
   57                     Successor.OnWithdraw( e );
   58                 }
   59             }
   60         }
   61 
   62         // "ConcreteHandler"
   63         class Officer : Approver
   64         {
   65             public Officer()
   66             {
   67                 // Hook up delegate to event
   68                 Withdraw += ProcessByOfficer;
   69             }
   70 
   71             public void ProcessByOfficer( Approver approver,
   72                 WithdrawArgs e )
   73             {
   74                 if ( e.Amount < 100000 )
   75                 {
   76                     Console.WriteLine( "{0} approved withdrawal for account : {1}",
   77                         GetType().Name, e.AccountNumber );
   78                 }
   79                 else if ( Successor != null )
   80                 {
   81                     Successor.OnWithdraw( e );
   82                 }
   83             }
   84         }
   85 
   86         // "ConcreteHandler"
   87         class Manager : Approver
   88         {
   89             public Manager()
   90             {
   91                 // Hook up delegate to event
   92                 Withdraw += ProcessByManager;
   93             }
   94 
   95             public void ProcessByManager( Approver approver, WithdrawArgs e )
   96             {
   97                 if ( e.Amount < 1000000 )
   98                 {
   99                     Console.WriteLine( "{0} approved withdrawal for account : {1}",
  100                         GetType().Name, e.AccountNumber );
  101                 }
  102                 else
  103                 {
  104                     Console.WriteLine( "Cannot be approved" );
  105                 }
  106             }
  107         }
  108 
  109         class WithDrawal
  110         {
  111             public double Amount { get; set; }
  112             public int AccountNumber { get; set; }
  113         }
  114 
  115         static void Main()
  116         {
  117             // Setup Chain of Responsibility
  118             var clerkAprover = new Clerk();
  119             var officerApprover = new Officer();
  120             var managerApprover = new Manager();
  121 
  122             clerkAprover.Successor = officerApprover;
  123             officerApprover.Successor = managerApprover;
  124 
  125             var withDrawal = new WithDrawal { AccountNumber = 1234, Amount = 1001 };
  126             clerkAprover.ProcessRequest( withDrawal );
  127 
  128             withDrawal = new WithDrawal { AccountNumber = 2345, Amount = 10000 };
  129             clerkAprover.ProcessRequest( withDrawal );
  130 
  131             withDrawal = new WithDrawal { AccountNumber = 3456, Amount = 100000 };
  132             clerkAprover.ProcessRequest( withDrawal );
  133 
  134             //Output : Clerk approved withdrawal for account : 1234
  135             //         Officer approved withdrawal for account : 2345
  136             //         Manager approved withdrawal for account : 3456
  137 
  138             Console.Read();
  139         }
  140     }
  141 }

As seen in the example there are 3 approvers for withdrawal as  a chain. The request is passed to the clerk and based on the amount the responsibility is transferred to the successive approver in the chain. We can use the chain of responsibility patter when we have more than one handler for a single request or we have a set of handler that vary dynamically.

In my next post I will be writing about the Command pattern.

1. Strategy Pattern
2. State Pattern

You can read about the Structural patterns from here.
You can read about the Creational patterns from here.

The template method pattern deals with enabling algorithms to defer certain steps. It doesn't change the structure of the algorithm but a few of their operations are handled elsewhere.

    1 namespace PatternsConsole
    2 {
    3     class TemplatePattern
    4     {
    5         //Interface for operations
    6         interface ISortStrategy
    7         {
    8             void Sort();
    9         }
   10 
   11         //Algorithm with template method
   12         class Algorithm
   13         {
   14             public void TemplateMethod(ISortStrategy sortStrategy)
   15             {
   16                 sortStrategy.Sort();
   17             }
   18         }
   19 
   20         //Concrete Class
   21         class SortByAge : ISortStrategy
   22         {
   23             public void Sort()
   24             {
   25                 PersonList.Sort( ( p1, p2 ) => p1.Age.CompareTo( p2.Age ) );
   26                 Console.WriteLine("Sort By Age");
   27                 foreach ( var person in PersonList )
   28                 {
   29                     Console.WriteLine( "Name : " + person.Name + " Age :" + person.Age);
   30                 }
   31             }
   32         }
   33 
   34         //Concrete Class
   35         class SortByName : ISortStrategy
   36         {
   37             public void Sort()
   38             {
   39                 PersonList.Sort( ( p1, p2 ) => p1.Name.CompareTo( p2.Name ) );
   40                 Console.WriteLine( "\nSort By Name" );
   41                 foreach ( var person in PersonList )
   42                 {
   43                     Console.WriteLine( "Name : " + person.Name + " Age :" + person.Age );
   44                 }
   45             }
   46         }
   47 
   48         class Person
   49         {
   50             public string Name { get; set; }
   51             public int Age { get; set; }
   52         }
   53 
   54         private static List<Person> PersonList;
   55 
   56         private static void Main()
   57         {
   58             PersonList = new List<Person>
   59                               {
   60                                   new Person {Name = "Person1", Age = 25},
   61                                   new Person {Name = "Person3", Age = 26},
   62                                   new Person {Name = "Person4", Age = 20},
   63                                   new Person {Name = "Person2", Age = 28}
   64                               };
   65 
   66             var sortAlgo = new Algorithm();
   67 
   68             sortAlgo.TemplateMethod( new SortByAge() );
   69             //Output :  Sort By Age
   70             //          Name : Person4 Age :20
   71             //          Name : Person1 Age :25
   72             //          Name : Person3 Age :26
   73             //          Name : Person2 Age :28
   74 
   75             sortAlgo.TemplateMethod( new SortByName() );
   76             //Output :  Sort By Name 
   77             //          Name : Person1 Age :25
   78             //          Name : Person2 Age :28
   79             //          Name : Person3 Age :26
   80             //          Name : Person4 Age :20
   81 
   82             Console.Read();
   83         }
   84     }
   85 }

We can use the template method pattern when common behavior can be outside the algorithm and the the behavior itself varies based on the type of the subclass.

In my next post I will be writing about the Chain of Responsibility pattern.

1. Strategy Pattern

You can read about Structural Patterns from here.

You can read about Creational Patterns from here.

State pattern in essence is a dynamic version of the strategy pattern, meaning, when the sate inside an object is changed, it could change its behavior.

    1 namespace PatternsConsole
    2 {
    3     class StatePattern
    4     {
    5         interface IState
    6         {
    7             void Deposit( double amount );
    8             void Withdraw( double amount );
    9 
   10             double Balance { get; set; }
   11             Account Account { get; set; }
   12         }
   13 
   14         // State 1
   15         class InsufficientState : IState
   16         {
   17             public InsufficientState( double balance, Account account )
   18             {
   19                 Balance = balance;
   20                 Account = account;
   21             }
   22 
   23             public void Deposit( double amount )
   24             {
   25                 Balance += amount;
   26                 CheckState();
   27             }
   28 
   29             public void Withdraw( double amount )
   30             {
   31                 Balance -= amount;
   32                 Console.WriteLine( "Insufficient fund" );
   33             }
   34 
   35             private void CheckState()
   36             {
   37                 if ( Balance > 100 )
   38                 {
   39                     Account.State = new NormalState( Balance, Account );
   40                 }
   41                 else if ( Balance > 300 )
   42                 {
   43                     Account.State = new GoldState( Balance, Account );
   44                 }
   45             }
   46 
   47             public double Balance { get; set; }
   48             public Account Account { get; set; }
   49         }
   50 
   51         // State 2
   52         class NormalState : IState
   53         {
   54             public NormalState( double balance, Account account )
   55             {
   56                 Balance = balance;
   57                 Account = account;
   58             }
   59 
   60             public void Deposit( double amount )
   61             {
   62                 Balance += amount;
   63                 CheckState();
   64             }
   65 
   66             public void Withdraw( double amount )
   67             {
   68                 Balance -= amount;
   69                 CheckState();
   70             }
   71 
   72             private void CheckState()
   73             {
   74                 if ( Balance < 100 )
   75                 {
   76                     Account.State = new InsufficientState( Balance, Account );
   77                 }
   78                 else if ( Balance > 300 )
   79                 {
   80                     Account.State = new GoldState( Balance, Account );
   81                 }
   82             }
   83 
   84             public double Balance { get; set; }
   85             public Account Account { get; set; }
   86         }
   87 
   88         // State 3
   89         class GoldState : IState
   90         {
   91             public GoldState( double balance, Account account )
   92             {
   93                 Balance = balance;
   94                 Account = account;
   95             }
   96 
   97             public void Deposit( double amount )
   98             {
   99                 Balance += amount;
  100                 CheckState();
  101             }
  102 
  103             public void Withdraw( double amount )
  104             {
  105                 Balance -= amount;
  106                 CheckState();
  107             }
  108 
  109             private void CheckState()
  110             {
  111                 if ( Balance < 100 )
  112                 {
  113                     Account.State = new InsufficientState( Balance, Account );
  114                 }
  115                 else if ( Balance < 300 )
  116                 {
  117                     Account.State = new NormalState( Balance, Account );
  118                 }
  119             }
  120 
  121             public double Balance { get; set; }
  122             public Account Account { get; set; }
  123         }
  124 
  125         // Context
  126         class Account
  127         {
  128             public IState State { set; get; }
  129 
  130             // Construcstor
  131             public Account()
  132             {
  133                 State = new NormalState( 0, this );
  134             }
  135 
  136             public void Deposit( double amount )
  137             {
  138                 State.Deposit( amount );
  139                 Console.WriteLine( "Deposited {0:C} ", amount );
  140                 Console.WriteLine( " Balance = {0:C}", State.Balance );
  141                 Console.WriteLine( " Status  = {0}", State.GetType().Name );
  142                 Console.WriteLine( "" );
  143             }
  144 
  145             public void Withdraw( double amount )
  146             {
  147                 State.Withdraw( amount );
  148                 Console.WriteLine( "Withdrew {0:C} ", amount );
  149                 Console.WriteLine( " Balance = {0:C}", State.Balance );
  150                 Console.WriteLine( " Status  = {0}\n", State.GetType().Name );
  151             }
  152         }
  153 
  154         static void Main()
  155         {
  156             var account = new Account();
  157 
  158             account.Deposit( 100 );
  159             account.Deposit( 100 );
  160             account.Deposit( 300 );
  161             account.Withdraw( 200 );
  162             account.Withdraw( 200 );
  163             account.Withdraw( 100 );
  164 
  165             // Output:
  166             // Deposited $100.00 
  167             // Balance = $100.00
  168             // Status  = NormalState
  169 
  170             // Deposited $100.00 
  171             // Balance = $200.00
  172             // Status  = NormalState
  173 
  174             // Deposited $300.00 
  175             // Balance = $500.00
  176             // Status  = GoldState
  177 
  178             // Withdrew $200.00 
  179             // Balance = $300.00
  180             // Status  = GoldState
  181 
  182             // Withdrew $200.00 
  183             // Balance = $100.00
  184             // Status  = NormalState
  185 
  186             // Withdrew $100.00 
  187             // Balance = $0.00
  188             // Status  = InsufficientState
  189 
  190             Console.Read();
  191         }
  192     }
  193 }

As you can see in the example, the behavior of our code is changing based on the state which internally is changed based on the amount balance. We can use the state pattern when we have objects that may change their behavior at runtime based on some context or when the objects are becoming complex with many conditional branches.

In my next post I will be writing about the Template Method Pattern

Behavioral Patterns

Behavioral patterns are concerned with algorithms and communication between them. An algorithm that may have been spilt into complex classes could be hard to maintain. Behavioral patterns helps in identifying the basis for this split and deals with communication between these classes.

Strategy Pattern

The strategy pattern deals with removing algorithms from its host and placing them separately. The client program is given a context to select the desired algorithm in a simple way.

    1 namespace PatternsConsole
    2 {
    3     class StrategyPattern
    4     {
    5         // Strategy Interface
    6         interface ISortStrategy
    7         {
    8             void Sort( List<Person> list );
    9         }
   10 
   11         class Person
   12         {
   13             public string Name { get; set; }
   14             public int Age { get; set; }
   15         }
   16 
   17         // Concrete Strategies
   18         class SelectionSort : ISortStrategy
   19         {
   20             public void Sort( List<Person> list )
   21             {
   22                 for (var i = 0; i < list.Count - 1; i++)
   23                 {
   24                     for ( var j = 1 + 1 ; j < list.Count; j++ )
   25                     {
   26                         if(list[i].Age > list[j].Age)
   27                         {
   28                             Swap(i, list, j);
   29                         }
   30                     }
   31                 }
   32             }
   33 
   34             private static void Swap(int i, IList<Person> list, int j)
   35             {
   36                 var temp = list[i];
   37                 list[i] = list[j];
   38                 list[j] = temp;
   39             }
   40         }
   41 
   42         class LINQSort : ISortStrategy
   43         {
   44             public void Sort( List<Person> list )
   45             {
   46                 list.Sort( ( p1, p2 ) => p1.Age.CompareTo( p2.Age ) );
   47             }
   48         }
   49 
   50         // Context
   51         class SortedList
   52         {
   53             private readonly List<Person> list = new List<Person>();
   54             public ISortStrategy SortStrategy { private get; set; }
   55 
   56             public void Add( Person person )
   57             {
   58                 list.Add( person );
   59             }
   60 
   61             public void Sort()
   62             {
   63                 SortStrategy.Sort( list );
   64                 Console.WriteLine( SortStrategy.GetType().Name);
   65                 foreach ( var person in list )
   66                 {
   67                     Console.WriteLine( " " + person.Name );
   68                 }
   69                 Console.WriteLine();
   70             }
   71         }
   72 
   73         private static void Main()
   74         {
   75             var list = new SortedList();
   76 
   77             list.Add( new Person { Name = "Person1", Age = 25 } );
   78             list.Add( new Person { Name = "Person2", Age = 28 } );
   79             list.Add( new Person { Name = "Person3", Age = 26 } );
   80             list.Add( new Person { Name = "Person4", Age = 20 } );
   81 
   82             list.SortStrategy = new SelectionSort();
   83             list.Sort();
   84 
   85             list.SortStrategy = new LINQSort();
   86             list.Sort();
   87             // Output : SelectionSort
   88             //          Person4
   89             //          Person1
   90             //          Person3
   91             //          Person2
   92 
   93             //          LINQSort
   94             //          Person4
   95             //          Person1
   96             //          Person3
   97             //          Person2
   98 
   99             Console.Read();
  100         }
  101     }
  102 }

As you can see in the above example, we have 2 strategies to sort a list. There is a context class which is exposed to the client where it can select a particular strategy. We can use the strategy pattern when we have different classes only differing in behavior or when there are different algorithms and we have to give the selection to the client.

In my next post I will write about the State Pattern.

1. Prototype Pattern
2. Factory Method Pattern
3. Singleton Pattern
4. Abstract Factory Pattern
5. Builder Pattern

You can read about Structural Patterns from here.

In the following posts to come, I will write about the Behavioral Patterns.

1. Prototype Pattern
2. Factory Method Pattern
3. Singleton Pattern
4. Abstract Factory Pattern

You can read about Structural Patterns from here.

The Builder pattern deals with separation of the specification of a complex object from its actual construction. This construction process can create different representations of the class.

    1 public class BuilderPattern
    2 {
    3 
    4     // Interface Car
    5     public interface ICar
    6     {
    7         string Details { get; set; }
    8     }
    9 
   10     // All concrete Cars
   11     class Car : ICar
   12     {
   13         public string Details { get; set; }
   14     }
   15 
   16     // Directors
   17     private interface IModel
   18     {
   19         ICar CreateCar();
   20     }
   21 
   22     //Individual car model
   23     public class Benz : IModel
   24     {
   25         public ICar CreateCar()
   26         {
   27             var car = new Car();
   28             DoWork("Build chassis");
   29             DoWork("Fit Engine");
   30             DoWork("Paint");
   31             car.Details = "Merc";
   32             return car;
   33         }
   34     }
   35 
   36     //Individual car model
   37     public class BMW : IModel
   38     {
   39         public ICar CreateCar()
   40         {
   41             var car = new Car();
   42             DoWork( "Build chassis" );
   43             DoWork( "Fit Engine" );
   44             DoWork( "Paint" );
   45             car.Details = "BMW";
   46             return car;
   47         }
   48     }
   49 
   50     public static void DoWork( string workitem )
   51     {
   52         Console.Write("" + workitem + ": 0%");
   53         Console.Write("....25%");
   54         Console.Write("....50%");
   55         Console.WriteLine("....100%");
   56     }
   57 
   58     //Builder that creates the car
   59     private interface IBuilder<T> where T : IModel
   60     {
   61         ICar CreateCar();
   62     }
   63 
   64     // Concrete Builder
   65     class Builder<T> : IBuilder<T> where T : IModel, new()
   66     {
   67 
   68         T myModel;
   69         public Builder()
   70         {
   71             myModel = new T();
   72         }
   73 
   74         public ICar CreateCar()
   75         {
   76             return myModel.CreateCar();
   77         }
   78     }
   79 
   80     class Client<T> where T : IModel, new()
   81     {
   82         public void ClientMain()
   83         {
   84             IBuilder<T> builder = new Builder<T>();
   85             Console.WriteLine("Building a car");
   86             var car = builder.CreateCar();
   87 
   88             Console.WriteLine( "Car Built : " + car.Details );
   89         }
   90     }
   91 
   92     private static void Main()
   93     {
   94         new Client<Benz>().ClientMain();
   95         new Client<BMW>().ClientMain();
   96 
   97         // Output : Building a car
   98         //          Build chassis: 0%....25%....50%....100%
   99         //          Fit Engine: 0%....25%....50%....100%
  100         //          Paint: 0%....25%....50%....100%
  101         //          Car Built : Merc
  102         //
  103         //          Building a car
  104         //          Build chassis: 0%....25%....50%....100%
  105         //          Fit Engine: 0%....25%....50%....100%
  106         //          Paint: 0%....25%....50%....100%
  107         //          Car Built : BMW
  108 
  109         Console.ReadLine();
  110     }
  111 }

The Builder pattern is based on Directors and Builders. Builder classes can confirm to an IBuilder interface, and they can be called by a director to produce a product according to specification. Builders can be found in applications that create complex structures. We can use the builder pattern when The object to be assembled might have different representations. or when you need fine control over the construction process.

In my next post I will start with the Behavioral patterns.

1. Prototype Pattern
2. Factory Method Pattern
3. Singleton Pattern

You can read about Structural Patterns from here.

Abstract factory pattern deals with creation of objects that are designed to be produced together. Abstract factory can be defined to create different objects of different types and in different combinations. This pattern isolates the object definitions and their class names so that only a factory can return an object when a client requires it.

    1 public class AbstractFactoryPattern
    2     {
    3         // An interface for all Cars
    4         private interface IModel
    5         {
    6             int Cost { get; }
    7             string Name { get; }
    8         }
    9 
   10         //Individual car model
   11         public class Benz : IModel
   12         {
   13             public int Cost
   14             {
   15                 get { return 20000; }
   16             }
   17 
   18             public string Name
   19             {
   20                 get { return "Merc"; }
   21             }
   22         }
   23 
   24         //Individual car model
   25         public class BMW : IModel
   26         {
   27             public int Cost
   28             {
   29                 get { return 21000; }
   30             }
   31 
   32             public string Name
   33             {
   34                 get { return "BMW"; }
   35             }
   36         }
   37 
   38         // Interface Car
   39         private interface ICar
   40         {
   41             string Name { get; }
   42             string Cost { get; }
   43         }
   44 
   45         // All concrete Cars
   46         class Car<T> : ICar where T : IModel, new()
   47         {
   48             private readonly T model;
   49 
   50             public Car()
   51             {
   52                 model = new T();
   53             }
   54 
   55             public string Name
   56             {
   57                 get { return model.Name; }
   58             }
   59 
   60             public string Cost
   61             {
   62                 get { return model.Cost.ToString(); }
   63             }
   64         }
   65 
   66         //Factory that creates the car
   67         private interface IFactory
   68         {
   69             ICar CreateCar();
   70         }
   71 
   72         // Concrete Factories
   73         class CarFactory<T> : IFactory where T : IModel, new()
   74         {
   75             public ICar CreateCar()
   76             {
   77                 return new Car<T>();
   78             }
   79         }
   80 
   81         class Client<T> where T : IModel, new()
   82         {
   83             public void ClientMain()
   84             {
   85                 IFactory factory = new CarFactory<T>();
   86                 var car = factory.CreateCar();
   87 
   88                 Console.WriteLine( "My car is " + car.Name + " and its cost is " + car.Cost );
   89             }
   90         }
   91 
   92         private static void Main()
   93         {
   94             new Client<Benz>().ClientMain();
   95             new Client<BMW>().ClientMain();
   96 
   97             //Output: My car is Merc and its cost is 20000
   98             //        My car is BMW and its cost is 21000
   99 
  100             Console.ReadLine();
  101         }
  102     }

As we can see from the above example, the abstract factory handles creation of objects and keeps their details hidden from the client. We can use the Abstract Factory pattern when a system should be independent of how its objects are created and represented or when a system can be configured with one of many families of products or when the importance is on revealing interfaces and not implementations.

In my next post I will writing about the Builder pattern.

1. Prototype Pattern
2. Factory Method Pattern

You can read about Structural Patterns from here.

Singleton pattern deals with ensuring that there is only one instance of a class and providing a single global access point to that object. It also ensures that the object is not created until its actually needed.

    1 class SingletonPattern
    2 {
    3     class SingletonPerson
    4     {
    5         private static SingletonPerson instance = null;
    6 
    7         public string Name { get; private set; }
    8         public int Age { get; private set; }
    9         public string Address { get; private set; }
   10 
   11         private Random random =  new Random();
   12 
   13         SingletonPerson()
   14         {
   15             Name = "Person" + random.Next( 1, 10 );
   16             Age = 27;
   17             Address = "Address" + random.Next(10, 20);
   18         }
   19 
   20         public static SingletonPerson Instance
   21         {
   22             get
   23             {
   24                 return Nested.Instance;
   25             }
   26         }
   27 
   28         private class Nested
   29         {
   30             internal static readonly SingletonPerson Instance =
   31                 new SingletonPerson();
   32 
   33             static Nested()
   34             {                
   35             }
   36         }
   37     }
   38 
   39     static void Main()
   40     {
   41         SingletonPerson person1 = SingletonPerson.Instance;
   42         Console.WriteLine( "Name  : " + person1.Name + " Age : " + person1.Age 
   43             + " Address : " + person1.Address );
   44         //Output : Name  : Person7 Age : 27 Address : Address19
   45 
   46         SingletonPerson person2 = SingletonPerson.Instance;
   47         Console.WriteLine( "Name  : " + person2.Name + " Age : " + person2.Age 
   48             + " Address : " + person2.Address );
   49         //Output : Name  : Person7 Age : 27 Address : Address19
   50 
   51         // Confirm person1 and person2 are same
   52         if ( person1 == person2 )
   53         {
   54             Console.WriteLine( "Same instance\n" );
   55         }
   56 
   57         Console.ReadLine();
   58     }
   59 }

As you can see from the above example the 2 instances of the SingletonPerson object are the same and so are their properties viz. Name, Age and Address.  We can use the singleton pattern when we need to create only one instance of a class or when we need to provide controlled access to an instance.

In my next post I will be writing about the Abstract Factory Pattern.

1. Prototype Pattern

You can read about Structural Patterns from here.

The Factory Method pattern deals with creation of objects in which the subclasses decide which class's object has to be created. Various subclasses may implement the same interface, but the Factory Method creates the appropriate object based on some supplied information.

    1 public class FactoryPattern
    2 {
    3     public interface IWorkLocation
    4     {
    5         string WorkingFrom();
    6     }
    7 
    8     public class Developer : Person, IWorkLocation
    9     {
   10         public Developer( string name, string designation )
   11         {
   12             this.Name = name;
   13             this.Designation = designation;
   14         }
   15 
   16         public string WorkingFrom()
   17         {
   18             return "Name : " + this.Name + ", Work Location :  Home";
   19         }
   20     }
   21 
   22     public class Tester : Person, IWorkLocation
   23     {
   24         public Tester( string name, string designation )
   25         {
   26             this.Name = name;
   27             this.Designation = designation;
   28         }
   29 
   30         public string WorkingFrom()
   31         {
   32             return "Name : " + this.Name + ", Work Location :  Office";
   33         }
   34     }
   35 
   36     public class Person : IWorkLocation
   37     {
   38         public string Designation { get; set; }
   39         public string Name { get; set; }
   40 
   41         public Person()
   42         {
   43             Name = "Base Person";
   44             Designation = "";
   45         }
   46 
   47         public Person( string name, string designation )
   48         {
   49             Designation = designation;
   50             Name = name;
   51         }
   52 
   53         public string WorkingFrom()
   54         {
   55             return "Name : " + this.Name + ", Work Location :  Not Available";
   56         }
   57     }
   58 
   59     //Creator
   60     public class Creator
   61     {
   62         public IWorkLocation FactoryMethod( Person per )
   63         {
   64             if ( per.Designation.Equals( "Developer" ) )
   65                 return new Developer( per.Name, per.Designation );
   66             else if ( per.Designation.Equals( "Tester" ) )
   67                 return new Tester( per.Name, per.Designation );
   68             else
   69                 return new Person();
   70         }
   71     }
   72 
   73     static void Main()
   74     {
   75         Creator crtr = new Creator();
   76         var person = crtr.FactoryMethod( new Person( "Person1", "Developer" ) );
   77         Console.WriteLine( person.WorkingFrom() );
   78         //Output: Name : Person1, Work Location :  Home
   79 
   80         person = crtr.FactoryMethod( new Person( "Person2", "Tester" ) );
   81         Console.WriteLine( person.WorkingFrom() );
   82         //Output: Name : Person2, Work Location :  Office
   83 
   84         person = crtr.FactoryMethod( new Person() );
   85         Console.WriteLine( person.WorkingFrom() );
   86         //Output:  Name : Base Person, Work Location :  Not Available
   87 
   88         Console.ReadLine();
   89     }
   90 }

As seen in the above example, the instantiation of objects is handled by the FactoryMethod of the Creator class. In this method, the information being passed helps the method in deciding which object to create. We must use the Factory method pattern when we want the flexibility of creating objects based on some criteria or the objects can be extended in subclasses.

In my next post I will talking about the Singleton pattern.

Creational Patterns

Creational patterns deals with separation of a system in terms of how their objects are created, what they are made of and how they must be represented. There are 5 types of creational patterns as observed by the GOF. I will write about the Prototype pattern today.

The Prototype

The prototype patterns deals with creation of new objects by cloning one of the available prototypes. The creation of objects is much faster for large classes. It also keeps a record of parts of a data structure so that it can be copied without knowing the subclass from which they were created.

    1 class PrototypePattern
    2 {
    3     [Serializable]
    4     public abstract class ProtoType<T> where T : class
    5     {
    6         public T ShallowCopy()
    7         {
    8             return this.MemberwiseClone() as T;
    9         }
   10 
   11         public T DeepCopy()
   12         {
   13             MemoryStream stream = new MemoryStream();
   14             BinaryFormatter formatter = new BinaryFormatter();
   15             formatter.Serialize( stream, this );
   16             stream.Seek( 0, SeekOrigin.Begin );
   17             T copy = formatter.Deserialize( stream ) as T;
   18             stream.Close();
   19             return copy;
   20         }
   21     }
   22 
   23     [Serializable]
   24     public class Address
   25     {
   26         public string Street { get; set; }
   27         public string City { get; set; }
   28         public string Country { get; set; }
   29 
   30         public Address( string street, string city, string country )
   31         {
   32             Street = street;
   33             City = city;
   34             Country = country;
   35         }
   36     }
   37 
   38     [Serializable]
   39     public class Person : ProtoType<Person>
   40     {
   41         public string Name { get; set; }
   42         public int Age { get; set; }
   43         public Address Address { get; set; }
   44 
   45         public Person( string name, int age, string street, string city, string country )
   46         {
   47             Name = name;
   48             Age = age;
   49             Address = new Address( street, city, country );
   50         }
   51 
   52         public override string ToString()
   53         {
   54             return string.Format( "Name : {0}\nAge : {1}\nAddress : {2}, {3}, {4}",
   55                 Name, Age, Address.Street, Address.City, Address.Country );
   56         }
   57     }
   58 
   59     class PersonManager : ProtoType<Person>
   60     {
   61         public Dictionary<string, Person> persons =
   62             new Dictionary<string, Person>()
   63                 {
   64                     { "person1", new Person("Person1", 25, "Street1", "City1", "Country1") },
   65                     { "person2", new Person("Person2", 26, "Street2", "City2", "Country2") }
   66                 };
   67     }
   68 
   69     static void Main()
   70     {
   71         PersonManager persManager = new PersonManager();
   72 
   73         Person person1, person2, person3, person4;
   74 
   75         person1 = persManager.persons["person1"];
   76         Console.WriteLine( person1.ToString() );
   77         // Output:  Name : Person1
   78         //          Age : 25
   79         //          Address : Street1, City1, Country1
   80 
   81         person3 = persManager.persons["person1"].ShallowCopy();
   82         person3.Name = "Person3";
   83         person3.Age = 20;
   84         person3.Address.Street = "Street3";
   85         person3.Address.City = "City3";
   86         person3.Address.Country = "Country3";
   87         Console.WriteLine( person3.ToString() );
   88         Console.WriteLine( person1.ToString() );
   89         // Output:  Name : Person3
   90         //          Age : 20
   91         //          Address : Street3, City3, Country3
   92         // Output:  Name : Person1
   93         //          Age : 25
   94         //          Address : Street3, City3, Country3
   95 
<