dotNet Musings | SimplyVinay

MPBlog Implementation. Part 5

2009-06-23T00:00:00+00:00

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());

Now that we have controllerfactory ready, we can configure our dependencies. The way to configure our dependency is through a registry which provides a fluent interface. The following code shows all the dependencies being loaded into the container through the MPBlogRegistry.

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.

MPBlog Implementation. Part 4

2009-05-18T00:00:00+00:00

NHibernate Repository and Unit Of Work

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 sessionthrough 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));
        }
    }
}

MPBlog Implementation. Part 3

2009-05-11T00:00:00+00:00

Mapping The Classes And Session Source Configuration

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.

A Brief Intermission

2009-04-15T00:00:00+00:00

I got a (few) comment by Colin on my previous post on the series that I had started.

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.

DDDBlog Implementation. Part 2

2009-04-08T00:00:00+00:00

In my previous post, we looked at setting up the project structure and the tools and libraries that we’ll need to build the application. In this post we’ll look at creating a few base classes.

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.

DDDBlog Implementation. Part 1

2009-04-06T00:00:00+00:00

In my pervious posts, I wrote about the aspects of TDD and DDD a bit, and following up on the series, I will start building the sample application from this post onwards. For the lack of better name, I will be calling the application DDDBlog.

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.

Aspects of TDD

2009-03-30T00:00:00+00:00

This post was supposed to be about the layering in my sample project, but I thought I would talk a bit about TDD as its new to me. This is by no means an exhaustive post on TDD

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

We write a failing test. We have to identity whether the test is testing what is intended in this step.
We make sure the test written in step 1 passes.
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.

Aspects Of DDD. Part II

2009-03-25T00:00:00+00:00

This is a continuation post. You can read the first part here.

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.

Aspects Of DDD. Part I

2009-03-23T00:00:00+00:00

What is DDD?

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.

My foray into DDD, TDD, MVC and NHibernate

2009-03-17T00:00:00+00:00

If you are closely following the things that are happening around the .NET development arena, there is a lot of interest in DDD ( Domain Driven Design ) along with other TLA’s like TDD ( Test Driven Development), MVC ( Model-View-Controller ) etc. It was hard for me not to notice the buzz around DDD and got me interested in it. As the title says, I would want to see what these things mean and how to develop an application around or rather using these technologies. 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.