A Default DDD Architecture with Auto-mapping Domain Entities

January 04, 2012

A Default DDD Architecture with Auto-mapping Domain Entities

Download source:

Introduction

The idea of this article is to develop a small tiny bare minimum framework in ASP.NET for any start-up project who wishes to embrace the domain driven design. Also you can easily plug this as part of your large framework. It basically tries to remove those tasks of a DDD project when used with an ORM as NHibernate which most developers find as tedious:

Writing and/or generating hbm mapping files for each domain entity
Generate corresponding ddl queries and run against the database
Write repositories for CRUD functionality on entities

A similar feature rich product is LightSpeed which has its own ORM. However, we will be using the most comprehensive ORM NHibernate and we can also easily use complex hbm mapping for legacy databases with our framework.
With the framework in place, one has to write only the domain model and can run CRUD operations on those using repositories provided.
The framework will provide these by automatic mapping of domain entities using Fluent NHibernate with an extendable predefined set of conventions. We will be able to easily switch between database(i.e compact to sql server) by merely changing NHibernate connection settings as the ORM will do the translation part for us. We will build a demo MVC 3 application on it demonstrating how we can start developing application by writing only the domain model, controllers and views and override of default mapping of a model. We will implement a database schema change management flow as the project evolves and the model changes.

Background

Seems like everybody is interested in developing the domain driven way. In the .Net community the power tools are the ASP.NET MVC 3 for presentation layer framework, NHibernate for ORM, Castle or spring for IOC, log4net for logging and so on. I assume reader is at least familiar with not all of these frameworks but at least ASP.NET MVC and the buzzword Domain Driven Design.
Although we can easily start a MVC 3 project from Visual Studio 2010 and write the models, and test CRUD functionality using mock frameworks like rhino mocks, but for a prototype built with all the actual persistence mechanism in place from the start would make us feel better, I believe.
And before start coding let me just give you a picture of the dependencies of our to be developed project:

Fig: generated by VS 2010 from Architecture->Generate Dependency Graph->by assembly from the solution

Note, MyFramework is a stand alone project.

Using the code

Environment Requirements: VS 2010 SP1, SQL COMPACT EDITION 4.0
First let me show the solution structure:

MyFramework - class library project which we are going to write. Stands alone, has no dependency on other projects.
NHAutoMvcDemo - demo MVC 3 application built to demonstrate using the framework.
MyTest - is a MS test project used here to generate and update/recreate the database schema

MyFramework – In VS 2010 We start with a class library project. As we will be using the automapping feature from fluent NHibernate we need to add reference to it through nuget. I used the Tools->Library Package Manger->Package Manager Console to install using command: PM> Install-Package FluentNHibernate
because the manage nuget user interface does not show the latest version 1.3 which supports NHibernate 3.2. From GUI interface it shows the version 1.2 which supports only upto NHibernate 3.1

In order to identify our entities (models which will be persisted) we define an abstract base class DomainEntiy.

namespace MyFrameWork.Domain
{
    public abstract class DomainEntity
    {        
        public virtual long Id { get; set; }
  
        public virtual string CreatedBy { get; set; }
        public virtual DateTime CreatedAt { get; set; }
        public virtual  string LastUpdatedBy { get; set; }
        public virtual DateTime LastUpdatedAt { get; set; }
  
        protected DomainEntity()
        {
            this.CreatedAt = DateTime.Now;
            this.LastUpdatedAt = DateTime.Now;
        }
    }
}

A class needs to derive from it in order to identify itself as a domain entity thus mapped to database table. This is the clue we will use (typeof(DomainEntity)) to identify entities and generate auto-mapping based on our conventions. This is also a good practice as we know our domain model will be Plain Old CLR Object (POCO), hence need not derive from any other special class. Also this class hosts some audit information which we desire to persist on every modification of entities.

We are not using the ClassMap<T> nor the hbmMapping xml here. Please note, NHibernate 3.2 already provides a similar classmap feature without Fluent NHibernate but I believe not the Fluent automapping. So, We will use fluent NHibernate’s defaultautomappingconfiguration as:

using System;
using FluentNHibernate;
using FluentNHibernate.Automapping;
using MyFrameWork.Domain;
  
namespace MyFrameWork.NHib
{
    public class FrameworkMappingConfiguration : DefaultAutomappingConfiguration
    {
        public override bool AbstractClassIsLayerSupertype(Type type)
        {
            return type == typeof(DomainEntity);
        }
  
        public override bool IsId(Member member)
        {
            return member.Name == "Id";
        }
  
        public override bool ShouldMap(Type type)
        {
            return
                type.BaseType == typeof(DomainEntity);
        }
  
        public override bool ShouldMap(Member member)
        {
            return base.ShouldMap(member) && member.CanWrite;
        } 
    }
}

This class defines which class type we should map, that is our entity which should derive from MyFramework.Domain.DomainEntity so we check type.BaseType == typeof(DomainEntity). It also defines how to recognize the ID field of entities. Note we will not use this implementation to configure fluent map. Rather we will create a persistent model generator. The purpose of the model generator would be to setup some conventions

Model generator – In First step we create an interface IAutoPersistenceModelGenerator and provide a default implementation. This interface also works as the plugging point for the consumer of the framework to provide its own implementation.

We write the conventions which resides in Conventions folder.

Finally our implementation of the model generator which sets up the conventions along with our Mapping configuration implementation.

using System.Collections.Generic;
using System.Reflection;
using System;
using FluentNHibernate.Automapping;
using FluentNHibernate.Conventions;
using MyFrameWork.Domain;
using MyFrameWork.NHib.Conventions;
  
namespace MyFrameWork.NHib
{
    public class AutoPersistenceModelGenerator : IAutoPersistenceModelGenerator
    {
        public List<Assembly> AutoMappingAssemblies { get; set; }
        public Assembly OverrideAssembly { get; set; }
  
        public AutoPersistenceModelGenerator()
        {
            AutoMappingAssemblies = new List<Assembly>();
            OverrideAssembly = Assembly.GetAssembly(typeof (DomainEntity));
        }        
  
        public AutoPersistenceModel Generate()
        {
            return
                AutoMap.Assemblies(new FrameworkMappingConfiguration(), this.AutoMappingAssemblies)
                    .Conventions.Setup(this.GetConventions())
                    .IgnoreBase<DomainEntity>()
                    .UseOverridesFromAssembly(this.OverrideAssembly);
        }
  
        private Action<IConventionFinder> GetConventions()
        {
            return c =>
                {
                    c.Add<PrimaryKeyConvention>();
                    c.Add<HasManyConvention>();
                    c.Add<TableNameConvention>();                    
                };
        }
    }
}

Now we are all set with the mapping configuration and conventions for automapping. So we implement the static NHibernateSession object to get the ISession.

Configuration

For brevity our config settings are taken from AppSettings like this:

<appSettings>
        <add key="MappingAssemblies" value="NHAutoMvcDemo;MyFrameWork" />        
        <add key="OverrideAssembly" value="NHAutoMvcDemo" />
        <add key="NHibConfigFile" value="nHibernate.config" />
        <add key="HbmExportPath" value="C:\" />
    </appSettings>

Here MappingAssemblies are assemblies which should be automapped and OverrideAssembly is the assembly from which we will use any default automap override for any number of entities. We see an example later about this in the demo app.

And as mentioned as NHibConfigFile, we will use NHibernate connection settings from nHibernate.config like:

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
    <session-factory>
        <property name="connection.connection_string">Data Source=C:\Users\latifur.rahman\Documents\Visual Studio 2010\Projects\DefaultDDDArch\NHAutoMvcDemo\App_Data\Demo_DB.sdf;</property>
        <property name="dialect">NHibernate.Dialect.MsSqlCeDialect</property>
        <property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property>
        <property name="connection.driver_class">NHibernate.Driver.SqlServerCeDriver</property>
        <property name="show_sql">true</property>
        <property name="connection.release_mode">on_close</property>        
  
        <!-- hbm2ddl tool property should NOT be used in production and is here to get you 
        going with the Cookbook! -->
        <!--<property name="hbm2ddl.auto">update</property>-->
        <!-- Mapping assemblies -->
        <!-- Can't map it for Fluent NHibernate here; instead, load the mapping assembly in Global.asax.cs.
            If you're still using HBMs, you can use the mapping here or pass the assembly via Global.asax.cs
            as well, just like you can do with the Fluent NHibernate assembly(s). -->
    </session-factory>
</hibernate-configuration>

The <property name="connection.release_mode">on_close</property> is for a hibernate bug when the database is sql compact.

Generic Repository
Finally we implement a minimal generic repository for CRUD functionality of entities.

Its pretty simple like :

using System.Collections.Generic;
using MyFrameWork.Domain;
  
namespace MyFrameWork.Repository.Contract
{
    public interface IRepository<T> where T : DomainEntity
    {        
        IList<T> GetAll();
  
        T Get(long id);
        
        T SaveOrUpdate(T entity);
        void Delete(T entity);
  
        void Delete(long id);
    }
}

And the implementation:

#region REFERENCES
using System.Collections.Generic;
using MyFrameWork.Domain;
using MyFrameWork.NHib;
using MyFrameWork.Repository.Contract;
using NHibernate;
  
#endregion REFERENCES
  
namespace MyFrameWork.Repository
{
    public class NhRepository<T> : IRepository<T> where T:DomainEntity
    {
        ISession Session { 
            get {
                return NHibernateSession.Initialize(null);
            } 
        }
  
        public virtual IList<T> GetAll()
        {
            ICriteria criteria = this.Session.CreateCriteria(typeof(T));
            return criteria.List<T>();
        }
  
        public T Get(long id)
        {
            return this.Session.Get<T>(id);
        }        
  
        public T SaveOrUpdate(T entity)
        {
            ISession session = this.Session;
            session.SaveOrUpdate(entity);
            session.Flush();
  
            return entity;
        }
  
        public void Delete(T entity)
        {
            this.Session.Delete(entity);
        }
  
        public void Delete(long id)
        {
            ISession session = this.Session;
            
            session.Delete(session.Get<T>(id));
            session.Flush();
        } 
    }
}

Note, we only provided the SaveOrUpdate, GetAll and Get. Also the consumer can override this default implementation to add search query features.

Also for every crud operations, we are configuring, initializing and building the session Annoyed

In ideal case the session would be initialized once in app_start and previously opened session will be reused. But I saved that for another post Winking smile

Demo MVC Application

Now we create an MVC 3 app with VS 2010 project template. The structure would be like this:

Entities:

Simple Bookstore Domain with with three entities: Author, Book, Publisher.
An author has written multiple books, A book can have multiple authors and a book must have a Publisher. A Publisher publishes multiple books.

Controllers:

Just added PublisherController to crud Publishers. And StoreController to add books with publisher relation here. Note, we haven’t deal with Author for brevity.

Mapping Override:

We demonstrate the override by making the Book.BookDescription property length as 2000 instead of default mapping generated length as nvarchar(255).

This is done at BookMappingOverride.cs

namespace NHAutoMvcDemo.DomainModels.MapOverrides
{
    public class BookMappingOverride : IAutoMappingOverride<Book>
    {
        public void Override(AutoMapping<Book> mapping)
        {
            mapping.Map(m => m.BookDescription).Length(2000);
        }
    }
}

Rest of the MVC like views controller implementation I believe can be rest assured as understandable.

Generate Schema and Execute DDL: Database change management

I have made a MS Test project MyTests

Added two test methods, one for recreate the whole database schema and other for try update the schema through alter table so that previous data remains untouched. Running tests outputs the script, so we can choose to run or not the ddl through SchemaExport or SchemaUpdate export argument as true/false by watching the scripts generated.

Here are the tests:

[TestMethod]
       public void DropAndRecreateSchema()
       {
           //
           // TODO: Add test logic here
           //
           MyFrameWork.NHib.NHibernateSession.Initialize(null);
  
           var config = NHibernateSession.Configuration;
  
           var schemaExport = new SchemaExport(config); 
           schemaExport.Execute(true, false, false);
       }
  
       [TestMethod]
       public void TryAlterDbSchema()
       {
           //
           // TODO: Add test logic here
           //
           MyFrameWork.NHib.NHibernateSession.Initialize(null);            
  
           var config = NHibernateSession.Configuration;
  
           var schemaUpdate = new SchemaUpdate(config);
           schemaUpdate.Execute(true, true);
       }

Now that we have executed the ddl, we can check the database from server explorer:

As the database schema is there, we can run the MVC application and play with the crud functionalities implemented merely by writing a single repository call.

We have achieved our goal! We can reuse the MyFramework.dll onto any other project with entities written deriving from DomainEntity and retrieve/save those entities through the generic Nhrepository.

Search This Blog

Beyond Good and Evil