public class Wheel { public void Roll()....

Review of ASP.NET MVC in Action

Nathan Stott — Mon, 06 Jul 2009 17:09:05 GMT

I recently read ASP.NET MVC in Action by Jeffrey Palermo, Ben Scheirman, and Jimmy Bogard. The publication is an excellent introduction to the the ASP.NET MVC framework. The authors provide excellent background on the problems facing the MS development community and the solutions that ASP.NET MVC has offered to these problems. These problems include the general ineptitude of the view engines with which traditional ASP development and even webforms development were driven.

ASP.NET MVC is the clear answer to seperation of concerns that webforms attempted to give us with the code-behind files. The introductory chapter will get the beginner up-and-running quickly. The diagrams illustrate the points that the concise text makes. Even those without any experience with an MVC framework will find the directions and explanations well-thought-out and easy to follow.

Beyond the introductory content, I was genuinely impressed with the depth that the authors dove into the community and the framework. Phil Haack's route debugger, a piece of code intimately familiar to those of us who have been following the development of the framework since its early days, is mentioned and code based upon it is provided. The authors discuss such advanced techniques as creating a custom controller factory, a must for those of us who employ dependency injection.

Each new concept is introduced with illustrative code examples. I was particularlly impressed with Chatper 9: Ajax in ASP.NET MVC. A note on unobrusive javascript reads:

You might notice throughout this chapter that I prefer unobtrusive Javascript. This means that the functionality of the page degrades gracefully in the absence of Javascript.

This shows careful attention by the authors to provide guidance on best practices. You will find this type of detail throughout the book. This is very refreshing because the Microsoft development community has lagged behind other communities in following wise guidelines and setting sensible best-practices.

The new Microsfot embrace of open-source is also made obvious as the authors present jQuery code in the AJAX chapter.

Chapter 10, hosting and deplpoyment, is a testament to the thoroughness with which the framework is covered. Deploying on IIS6 and earlier, something that can be quite tricky, is covered well. The configuration option of using .aspx extensions as well as the option to use URL rewriting are covered. URL rewriting can be quite difficult, but the authors provide examples to bring it all together.

The ASP.NET MVC framework is a breath of fresh-air for the Microsoft development world. It is a sensible, logical framework that allows extensability. ASP.NET MVC and WCF are the two best frameworks that Microsoft has ever produced in my opinion.

ASP.NET MVC in Action will guide you from your first project through advanced topics such as AJAX and deploying on suboptimal (read IIS6) hosting environments. The writing style is clear and concise. Diagrams and code examples are abundant. I recommend it for anyone looking for a great resource for learning about or becoming a better user of the ASP.NET MVC framework.

ASP.NET MVC Domain Driven Design Deux

Nathan Stott — Fri, 06 Mar 2009 16:21:57 GMT

Series Navigation

Entity Equality

We've got some more house keeping to do on our Entity object before proceding. Because entities are comporable based upon Id, a standard use of the == operator will produce undesirable results. When using an ORM, this is particularly important. You will often have instances of objects, especially objects in child relationships, that are the same as, but not reference equal to, one another.

Test Cases for Desired Entity Equality Behavior

I'm a believer in documentation via test cases, so here are my test cases that demonstrate the desired behavior:

    [TestFixture]
    public class EntityEqualityContext
    {
        [Test]
        public void TwoTransientEntitiesShouldNotBeEqual()
        {
            var entity1 = new TestEntity();
            var entity2 = new TestEntity();
 
            Assert.AreNotEqual(entity1, entity2, "Different transient entities should not be equal.");
        }
 
        [Test]
        public void TwoReferencesToSameTransientEntityShouldBeEqual()
        {
            var entity1 = new TestEntity();
            var entity2 = entity1;
 
            Assert.AreEqual(entity1, entity2, "Two references to the same transient entity should be equal.");
        }
 
        [Test]
        public void EntitiesWithSameIdShouldBeEqual()
        {
            var entity1 = new TestEntity();
            var entity2 = new TestEntity();
 
            entity1.SetId(1);
            entity2.SetId(1);
 
            Assert.AreEqual(entity1, entity2, "Entities with same id should be equal.");
        }
 
        [Test]
        public void EntitiesWithDifferentIdShouldNotBeEqual()
        {
            var entity1 = new TestEntity();
            var entity2 = new TestEntity();
 
            entity1.SetId(1);
            entity2.SetId(2);
 
            Assert.AreNotEqual(entity1, entity2, "Entities with different ids should not be equal.");
        }
 
        [Test]
        public void EntityShouldNotEqualTransientEntity()
        {
            var entity1 = new TestEntity();
            entity1.SetId(1);
 
            var entity2 = new TestEntity();
 
            Assert.AreNotEqual(entity1, entity2, "Entity and transient entity should not be equal.");
        }
 
        [Test]
        public void EntitiesWithSameIdButDifferentTypesShouldNotBeEqual()
        {
            var entity1 = new TestEntity();
            var entity2 = new OtherEntity();
 
            entity1.SetId(1);
            entity2.SetId(1);
 
            Assert.AreNotEqual(entity1, entity2, "Entities of different types should not be equal even if they have the same id.");
        }
 
        /// <summary>
        /// A test entity class created so that we can excercise 
        /// the functionality of the entity equaltiy members.
        /// </summary>
        public class TestEntity : Entity
        {
            private int id;
 
            public override int Id
            {
                get { return id; }
            }
 
            public void SetId(int id)
            {
                this.id = id;
            }
        }
 
        public class OtherEntity : Entity
        {
            private int id;
 
            public override int Id
            {
                get { return id; }
            }
 
            public void SetId(int id)
            {
                this.id = id;
            }
        }
    }

Summarized, these tests say that entities with id of 0 should only be equal if they are the same object. This is reference equality. Entities with an id should be equal if their ids are equal and they are of the same type. This is identity equality.

Entity with Equaltiy Members

    public abstract class Entity: IEquatable<Entity>
    {
        private int id;
        private int transientHashCode;
 
        public virtual int Id { get { return id; } }
 
        public override bool Equals(object obj)
        {
            return Equals(obj as Entity);
        }
 
        public virtual bool Equals(Entity obj)
        {
            if (obj == null) return false;
 
            if (IsTransient)
            {
                return ReferenceEquals(this, obj);
            }
 
            return obj.Id == Id && obj.GetType() == GetType();
        }
 
        public override int GetHashCode()
        {
            if (IsTransient)
            {
                if (transientHashCode == 0)
                {
                    transientHashCode = base.GetHashCode();
                }
                return transientHashCode;
            }
            return id;
        }
 
        private bool IsTransient
        {
            get { return Id == 0; }
        }
    }

For more information about why insuring that your entity equality is in order, please see The NHibernate FAQ.

As this is a blog example, we will need a class to represent posts.

The Post Class

    public class Post : Entity, IEquatable<Post>
    {
        public virtual string Title { get; set; }
 
        public virtual string Body { get; set; }
 
        /// <summary>
        /// Indicates whether the current object is equal to another object of the same type.
        /// </summary>
        /// <returns>
        /// true if the current object is equal to the <paramref name="other" /> parameter; otherwise, false.
        /// </returns>
        /// <param name="other">
        /// An object to compare with this object.
        /// </param>
        public virtual bool Equals(Post other)
        {
            return base.Equals(other);
        }
    }

In the future, we will add other properties like a collection of comments. For now, we will keep it simple in order to demonstrate the fluent mapping.

What's the Deal with the Virtual Members

NHibernate makes use of proxies for advanced features like lazy loading. The default proxy factory uses Castle's DynamicProxy. DyanmicProxy generates inheritance based proxies; therefore, it can only work if members are marked as virtual so that it can override them. There are other proxy choices; however, I will not be covering them. Making members virtual is a small price to pay for the conveniance in my opinion.

Mapping the Post Entity to the Database

Generating the mappings for your entities could not be easier with fluent nhibernates automapper.

Here is a simple utitliy class to add to the Service project:

    public class DomainMapper
    {
        private readonly IPersistenceConfigurer persistenceConfigurer;
 
        public DomainMapper(IPersistenceConfigurer persistenceConfigurer)
        {
            this.persistenceConfigurer = persistenceConfigurer;
        }
 
        public void Configure(Configuration configuration)
        {
            Fluently.Configure(configuration).Mappings(mapping => mapping.AutoMappings.Add(GetMapper())).Database(
                persistenceConfigurer).BuildSessionFactory();
        }
 
        protected virtual AutoPersistenceModel GetMapper()
        {
            var persistenceModel = new AutoPersistenceModel(typeof (Entity).Assembly)
                .Where(type => !type.IsAbstract && typeof (Entity).IsAssignableFrom(type))
                .WithConvention(convention =>
                                    {
                                        convention.IdConvention =
                                            id => id.Access.AsReadOnlyPropertyThroughCamelCaseField().GeneratedBy.HiLo(100.ToString());
                                        convention.IsBaseType = type => type == typeof (Entity);
                                        convention.DefaultStringLength = 255;
                                    });
            return persistenceModel;
        }
    }

I like to use HiLo for the id convention and avoid using Native Identity. For more information about the identity generators available using NHibernate, please see Vadi's Rants.

The DefaultStringLength is just a personal preference. The default is 100 if you do not specify a convention.

The IsBaseType is necesarry so fluent nhibernate does not create joined table entities from everything that inherits from Entity.

In the Blog.Service.Test project, add this utility class:

    public class TestDomainMapper: DomainMapper
    {
        public TestDomainMapper() : base(SQLiteConfiguration.Standard.InMemory().ShowSql())
        {
        }
    }

This class simply inerits from DomainMapper and provides a SQLite in memory database as the persistence configuration. Using an in memory database for our tests will make them run much faster. As the project grows, it is advisable to also run your integration tests vs the actual database that you will be using; however, running them against an in memory database during standard development saves time and is very conveniant.

In my first post, I attempted to make a thorough list of the tools that would be used in the project. I neglected at least one though: SQLite. I may have neglected more, so do not be surprised if we have to add more binaries throughout the series to our libraries directory. System.Data.SQLite can be downloaded here. Add it to trunk/libraries/sqlite and reference it from the Blog.Service.Test project.

Fluent NHibernate provides a useful helper for integration tests: PersistenceSpecification<T>. Here is what the initial Post integration test looks like:

[TestFixture]
public class MappingIntegrationContext
{
    protected ISession Session { get; private set; }
 
    [SetUp]
    public void BeforeEachTest()
    {
        var configuration = new Configuration();
        new TestDomainMapper().Configure(configuration);
 
        var sessionFactory = configuration.BuildSessionFactory();
        Session = sessionFactory.OpenSession();
 
        IDbConnection connection = Session.Connection;
 
        string[] scripts = configuration.GenerateSchemaCreationScript(Dialect.GetDialect(configuration.Properties));
        scripts.ToList().ForEach(script =>
                                     {
                                         var cmd = connection.CreateCommand();
                                         cmd.CommandText = script;
                                         cmd.ExecuteNonQuery();
                                     });
 
        Session.Flush();
    }
 
    [Test]
    public void PostIntegrationTest()
    {
        new PersistenceSpecification<Post>(Session)
            .CheckProperty(x => x.Title, "A Test Post")
            .CheckProperty(x => x.Body, "This is where the content of my post will be.  Yay.")
            .VerifyTheMappings();
    }
}

This is a good start, but obviously as our domain model grows and we need more test classes, this SetUp can be abstracted into its own base class that other test classes can inherit from.

public abstract class FixtureBase
{
    [SetUp]
    public void BeforeEachTest()
    {
        var configuration = new Configuration();
        new TestDomainMapper().Configure(configuration);
 
        var sessionFactory = configuration.BuildSessionFactory();
        Session = sessionFactory.OpenSession();
 
        IDbConnection connection = Session.Connection;
 
        string[] scripts = configuration.GenerateSchemaCreationScript(Dialect.GetDialect(configuration.Properties));
        scripts.ToList().ForEach(script =>
                                     {
                                         var cmd = connection.CreateCommand();
                                         cmd.CommandText = script;
                                         cmd.ExecuteNonQuery();
                                     });
 
        Session.Flush();
    }
 
    protected ISession Session { get; private set; }
}

Now the noise of the SetUp method can be taken out of the MappingIntegrationContext and we have a reusable base class for future test classes.

Implementing IRepository

Next, we will implement our repository. NHibernate.Burrow AppBlock makes this trivial. Reference NHibernate.Burrow.AppBlock from the Blog.Service assembly.

using System.Collections.Generic;
using Blog.Domain;
using NHibernate.Burrow.AppBlock.DAOBases;
 
namespace Blog.Service
{
    public class Repository<T>: GenericDAO<T>, IRepository<T> where T : Entity
    {
        /// <summary>
        /// Find an entity by unique identifier.
        /// </summary>
        /// <param name="id">Unique identifier of the entity.</param>
        /// <returns>Entity if found, <c>null</c> otherwise.</returns>
        public T Find(int id)
        {
            return base.Get(id);
        }
 
        /// <summary>
        /// Find all entities.
        /// </summary>
        /// <returns>Sequence of entities found.</returns>
        public new IEnumerable<T> FindAll()
        {
            return base.FindAll();
        }
 
        /// <summary>
        /// Save (insert or update as appropriate) <paramref name="entity"/> on next commit of the unit of work.
        /// </summary>
        /// <param name="entity">Entity to be saved.</param>
        public new void Save(T entity)
        {
            base.Save(entity);
        }
 
        /// <summary>
        /// Delete <paramref name="entity"/> on next commit of the unit of work.
        /// </summary>
        /// <param name="entity">Entity to be deleted.</param>
        public new void Delete(T entity)
        {
            base.Delete(entity);
        }
    }
}

For the basic functionality, AppBlock provides everything that we need.

Update: Some of you want the sample project that I am working from, so I will add a zip of it soon.

In the next post, we will wire up the Inversion of Control in our MVC app and create a controller for Post CRUD.

ASP.NET MVC Domain Driven Design

Nathan Stott — Sun, 01 Mar 2009 19:12:27 GMT

Series Navigation

Introduction

In this series of posts, I will detail how I setup projects using the principles of domain driven design in ASP.NET MVC.

The tools and libraries we will use are as follows:

The sample app will be the canonical blog example. This series will be light on the discussion of the theory of DDD and heavy on the nuts and bolts of asp.net MVC implementation.

Project Structure

Create a new directory for the project. I'm calling mine DDDSample. Following subversion convention, create a trunk and branches folder inside of DDDSample. Inside of trunk, create three directories: src, tools, and libraries.

The 'src' directory is where our code will go. The 'tools' directory will have NUnit and in the future, NAnt. The 'libraries' directory will contain the third party binaries that the project references.

Gathering the Libraries and Tools

1) Download the latest binary of fluent nhibernate from http://fluentnhibernate.org/downloads. Put the fluent nhibernate binaries in trunk/libraries/fluent-nhibernate.

2) Download NHibernate.Burrow from http://sourceforge.net/project/showfiles.php?group_id=216446. Put the burrow binaries in trunk/libraries/nhibernate.burrow. Important Note: Sometimes the latest version of NHibernate.Burrow will not have been built against the same version of NHibernate as fluent nhibernate was. Therefore, it is important that you be able to build NHibernate.Burrow, and the rest of the libraries that follow, from source. NHibernate.Burrow is a part of NHContrib. The NHContrib svn repository is located at https://nhcontrib.svn.sourceforge.net/svnroot/nhcontrib/trunk. There is a build script in the root directory of the NHibernate.Burrow subdirectory of the project. To rebuild with a different version of NHibernate, just replace the NHibernate dll in NHibernate.Burrow/lib/NHibernate with the binary of NHibernate from the fluent nhibernate.

3) Download NUnit from http://www.nunit.org/index.php?p=download. Get the zip distribution . Unzip the entire contents into trunk/tools/nunit. It is important that you include the full NHibernate distribution with your project so when we add an automated build tool later it will be able to run the unit tests without assuming that every developer has installed the correct version of NUnit from msi.

4) Download Moq from http://code.google.com/p/moq/downloads/list. Put the binaries in trunk/libraries/moq.

5) Download MVCContrib from http://www.codeplex.com/MVCContrib. Put the binaries in trunk/libraries/mvccontrib.

As an added measure of safety against change, I like to reference the MVC libraries themselves from binaries I store in my svn repository instead of from source. You don't have to do this, but if you choose to, I put System.Web.Mvc, System.Web.Routing, and System.Web.Abstractions in trunk/libraries/mvc.

Your completed project structure should look like this:

Creating the Projects

Our mvc project and class libraries will go in trunk/src.

Create an asp.net MVC project. For this sample, I'm calling mine Blog.Web.

Create two class libraries: Blog.Domain and Blog.Service. Blog.Domain is where our POCO (Plain Old C# Objects) entities and our repository interfaces will reside. Blog.Service is where the business logic that ties the application together will live.

Reference Blog.Domain and Blog.Service from Blog.Web. Reference Blog.Domain from Blog.Service.

Create a new solution folder (right click on project, hover over add, choose new solution folder) called Test. This is where our test projects will go.

Create three class libraries: Blog.Web.Test, Blog.Domain.Test, and Blog.Service.Test. In each of these projects reference NUnit.Framework from /trunk/tools/nunit.

More test projects may be needed later for separating unit tests from integration tests, but this is how I like to start with one unit test project for each of my projects.

The solution should now look like this:

Entity Base Class

In the domain, create an object ot be the base class for entities. An entity is an object that has an identity.

    1 namespace Blog.Domain
    2 {
    3     public abstract class Entity
    4     {
    5         private int id;
    6 
    7         public virtual int Id { get { return id; } }
    8     }
    9 }

There is no way to set the id property of the Entity base class. This is by design. Our persistence layer will use NHiberante generators to generate the identity values when we save new entities to the database.

Repositories

Just what are repositories? Repositories are an abstraction of the way we manage aggregates. Repositories should correspond only to aggregate roots. An aggregate is a cluster of objects that are treated as a unit. The aggregate root is the root object of the unit.

In Domain Driven Design, the repository interfaces are a part of the domain, but the implementations are not.

Generic Repository of Entities

All entity repositories will need some base functionality, so we define IRepository<T> with some basic methods that we expect any repository to need.

    1 using System.Collections.Generic;
    2 
    3 namespace Blog.Domain
    4 {
    5     /// <summary>
    6     /// Repository of entities.  
    7     /// </summary>
    8     public interface IRepository<T> where T : Entity
    9     {
   10         /// <summary>
   11         /// Find an entity by unique identifier.
   12         /// </summary>
   13         /// <param name="id">Unique identifier of the entity.</param>
   14         /// <returns>Entity if found, <c>null</c> otherwise.</returns>
   15         T Find(int id);
   16 
   17         /// <summary>
   18         /// Find all entities.
   19         /// </summary>
   20         /// <returns>Sequence of entities found.</returns>
   21         IEnumerable<T> FindAll();
   22 
   23         /// <summary>
   24         /// Save (insert or update as appropriate) <paramref name="entity"/> on next commit of the unit of work.
   25         /// </summary>
   26         /// <param name="entity">Entity to be saved.</param>
   27         void Save(T entity);
   28 
   29         /// <summary>
   30         /// Delete <paramref name="entity"/> on next commit of the unit of work.
   31         /// </summary>
   32         /// <param name="entity">Entity to be deleted.</param>
   33         void Delete(T entity);
   34     }
   35 }

Conclusions

In this post we have done a lot of nuts and bolts work. The amount of setup required may seem daunting, but as stated earlier, the third party tools and libraries will pay dividends in the long-run.

In the next post, we will create a Post entity, create a concrete implementation of IRepository<Post> using NHibernate, map Post to a database using Fluent NHibernate, and test our persistence model.

Register Repository Implementations Automatically with a Castle Facility

Nathan Stott — Thu, 26 Feb 2009 17:52:34 GMT

Isn't it annoying to have to register all your repository implementations by hand? When you get to a certain number of them, it becomes quite a task. If you want to register them for multiple interfaces, it gets even worse.

When using Windsor as your inversion of control container, separating your repository registrations into a facility is a good start. In general though, all our repositories follow a simple pattern and should be easily registerable automatically following an algorithm.

Domain driven design tells us that the repository interfaces are a part of the domain but the implementations are not. Therefore, we usually have two assemblies that are important.

This is a typical project layout:

Our facility needs to allow us to configure what assemblies it searches for types and the base type of the repository.

Specification

Here is a simple test describing the desired behavior:

    [TestFixture]
    public class RepositoryRegistrationFacilityTestFixture
    {
        [Test]
        public void ShouldRegisterCustomerRepository()
        {
            var kernel = new Castle.MicroKernel.DefaultKernel();




            var facility = new RepositoryRegistrationFacility(typeof (IRepository<>), typeof (Customer).Assembly);


            facility.Init(kernel,
                new Castle.Core.Configuration.MutableConfiguration("facility-config"));




            kernel.Resolve<ICustomerRepository>().ShouldBeInstanceOfType(typeof (CustomerRepository));
            kernel.Resolve<IRepository<Customer>>().ShouldBeInstanceOfType(typeof (CustomerRepository));

        }




        protected interface IRepository<T>
        {
        }
        protected interface ICustomerRepository : IRepository<Customer>
        {    
        }
        protected class CustomerRepository : ICustomerRepository
        {
        }
        protected class Customer
        {
        }
    }

Implementation

    public class RepositoryRegistrationFacility : AbstractFacility
    {
        private readonly Assembly[] assemblies;
        private readonly Type genericRepositoryType;

        public RepositoryRegistrationFacility(Type genericRepositoryType, params Assembly[] assemblies)
        {
            this.assemblies = assemblies;
            this.genericRepositoryType = genericRepositoryType;
        }

        protected override void Init()
        {
            Predicate<Type> isGenericRepositoryInterface =
                type =>
                type.GetInterfaces().Contains(
                    x => x.IsGenericType && x.GetGenericTypeDefinition().IsAssignableFrom(genericRepositoryType));

            IEnumerable<Type> types =
                assemblies.Aggregate(Enumerable.Empty<Type>(), (accumulator, assembly) => accumulator.Concat(assembly.GetTypes()));

            IEnumerable<Type> repositoryInterfaces = types.Where(
                type => type.IsInterface && !type.IsGenericTypeDefinition && isGenericRepositoryInterface(type));

            repositoryInterfaces
                .ForEach(interfaceType =>
                             {
                                 Type implementor =
                                     types.FirstOrDefault(type => interfaceType.IsAssignableFrom(type) && !type.IsAbstract);
                                 if (implementor == null) return;

                                 IEnumerable<Type> genericRepositoryInterfaceTypes = implementor.GetInterfaces().Where(
                                     x =>
                                     x.IsGenericType &&
                                     x.GetGenericTypeDefinition().IsAssignableFrom(genericRepositoryType));

                                 Kernel.Register(
                                     Component.For(interfaceType).ImplementedBy(implementor).Forward(
                                         genericRepositoryInterfaceTypes));
                             });
        }
    }

Now in fluent configuration you can just do this:

container.AddFacility("persistent-repository-facility", new RepositoryRegistrationFacility(typeof(IRepository<>), typeof(IRepository<>).Assembly, typeof(SomethingRepository).Assembly));

I have not tested the binsor registration, but you should be able to do something like this to register it using binsor:

facility RepositoryRegistrationFacility:
    genericRepositoryType: IRepository
    assemblies: array(System.Reflection.Assembly, IRepository.Assembly, SomethingRepository.Assembly)

I hope this is useful.

Building Domain Specific Languages in Boo by Oren Eini

Nathan Stott — Sat, 31 Jan 2009 19:39:00 GMT

Building Domain Specific Languages (DSL) in Boo by Oren Eini leads the intermediate to advanced programmer through the process of building several DSLs in the Boo programming language. It is not an introduction to Boo, but rather it is assumed that the user is advanced enough so that picking up a new language is not an insurmountable prerequisite. A Boo tutorial and reference is provided in the appendix.

The writing style is inviting an informal. The first two paragraphs will immediately endear programmers to Oren Eini:

At first, there was the bit. And the bit shifted left, and the bit shifted right, and there was the byte. The byte grew into a word, and then into double word. And the developer saw the work and it was good. And the evening and the morning were the first day.

And on the next day, the developer came back to the work and couldn’t figure out what he was thinking last night, and spent the whole day figuring that out.

Oren chose to write about building DSLs in Boo specifically because of the excellent language-oriented programming features available in the Boo programming language. This is not a book about the nuts and bolts of building a language from scratch. That would not truly be a treatise on DSLs as the purpose of DSLs is increased abstraction. That increased abstraction drives Oren’s craft. He makes no reservations about the fact that code maintainability and not performance is his primary concern.

This is a book about getting your feet wet and jumping right into building usable real-world DSLs. This book is immediately applicable to the work performed by hundreds of thousands of programmers every day. The DSLs presented in the book are pertinent to the work of enterprise developers. Thorough code samples of the fully functional DSLs are provided.

Rhino DSL is Oren’s low-level implementation of a language factory. It is leveraged throughout the book. Sufficient detail into the design goals and implementation of the library are given so that it could be easily reproduced even if it were not freely available as open source. Rhino DSL is licensed under the BSD license. I have used it. It is wonderful and I see no reason to reinvent the wheel.

Testing, versioning, and creating IDEs to polish your DSLs are topics treated thoroughly. Oren teaches you how and when to version your DSL. He presents several strategies for versioning. He drives home the points that automated testing is not an option, it’s a requirement.

I found the chapter on creating an IDE invaluable. Oren recommends using Sharp Develop. It is freely distributable and allows you to build a stand-alone DSL editor to distribute as a part of your package. The chapter begins by demonstrating how to provide a good text editing experience with syntax highlighting and code completion and then moves on to advanced topics such as how to create visualizations to round out the editing experience. This task is made easier thanks to the ability to use the abstract syntax tree (AST) provided by the Boo Parser. Score another one for Boo!

Not all of Oren’s advice is about programming itself. He provides insights into the business-aspect of creating DSLs as well. The first emphasis box in the documentation chapter is titled “Ensure an initial positive impression.” The common-sense statements in this box provide polish to the book, much as he is trying to teach the reader how to provide polish to a DSL.

These sentences captured my interest intently:

A project that looks good is pleasant to use, easier to demo and in general easier to get funding for.

The first stage should be a very easy one, even if you have to design to enable that specifically.

How often as programmers do we neglect to create a good first-impression of our amazing products? The code is well-tested and flawless, but it takes another computer scientist of equal skill an hour to get anything working.

Oren’s blend of humor and common-sense advice makes the book a joy to read. His example code and discussion of abstract concepts will challenge you to become a better programmer. Oren brings you into his world, one where everything is done correctly. All code is maintainable, self-documenting, and easy-to-read.

If you are a .NET developer, I cannot encourage you enough to pick up this book. Oren’s thoughts are valuable even if you never write a DSL. The concepts of language-oriented programming are becoming more main-stream, and this book is an excellent introduction that will open your eyes to the practical implications of language-oriented design.

State Pattern

Nathan Stott — Mon, 01 Sep 2008 20:12:24 GMT

State Pattern

The state pattern is a behavioral pattern that allows an object to partially change its type at runtime. This is useful in situations where we can not change the type of a base object, but wish to represent the state of it in encapsulated classes.

Let us consider a payroll system where employees are compensated and promoted based upon their current position.
We could use a property to store the employees current position.

    public class Employee
    {
        public string Name { get; set; }

        public EmployeePosition Position { get; set; }

        public void Promote()
        {
            switch (Position)
            {
                case EmployeePosition.JuniorDeveloper:
                    Position = EmployeePosition.SeniorDeveloper;
                    break;
                case EmployeePosition.SeniorDeveloper:
                    Position = EmployeePosition.TechnicalLead;
                    break;
                case EmployeePosition.TechnicalLead:
                    // This is as high as it goes.                     
                    break;
            }
        }

        public void Compensate(Accounting accounting)
        {
            int salary = 0;

            switch (Position)
            {
                case EmployeePosition.JuniorDeveloper:
                    salary = 40000;
                    break;
                case EmployeePosition.SeniorDeveloper:
                    salary = 75000;
                    break;
                case EmployeePosition.TechnicalLead:
                    salary = 100000;
                    break;
            }

            accounting.Pay(this, salary);
        }
    }

    public enum EmployeePosition
    {
        JuniorDeveloper,
        SeniorDeveloper,
        TechnicalLead
    }

    public class Accounting
    {
        public void Pay(Employee employee, int dollars)
        {
            // Pay the employee         
        }     
    }

This code is brittle. Changing the EmployeePosition enum requires changing multiple methods in the Employee domain object. The logic is spread thin and the encapsulation is non-existent.

A Better Way

A better way to do this is to use the state pattern. With the state pattern, the EmployeePosition enum is replaced by an abstract class representing the employees current position.

    public abstract class AbstractEmploymentState
    {
        private readonly Employee employee;

        public AbstractEmploymentState(Employee employee)
        {
            this.employee = employee;
        }

        protected virtual Employee Employee { get { return employee; } }

        public abstract void Promote();

        public abstract void Compensate(Accounting accounting);
    }

    public class Employee
    {
        private AbstractEmploymentState employmentState;
        public string Name { get; set; }

        public AbstractEmploymentState EmploymentState
        {
            get { return employmentState; }
            set { employmentState = value; }
        }

        public void Promote()
        {
            EmploymentState.Promote();
        }

        public void Compensnate(Accounting accounting)
        {
            EmploymentState.Compensate(accounting);
        }
    }

    public class JuniorDeveloperState: AbstractEmploymentState
    {
        public JuniorDeveloperState(Employee employee) : base(employee)
        {
        }

        public override void Promote()
        {
            Employee.EmploymentState = new SeniorDeveloperState(Employee);
        }

        public override void Compensate(Accounting accounting)
        {
            accounting.Pay(Employee, 40000);
        }
    }

    public class SeniorDeveloperState: AbstractEmploymentState
    {
        public SeniorDeveloperState(Employee employee) : base(employee)
        {
        }

        public override void Promote()
        {
            Employee.EmploymentState = new TechinicalLeadState(Employee);
        }

        public override void Compensate(Accounting accounting)
        {
            accounting.Pay(Employee, 75000);
        }
    }

    public class TechinicalLeadState: AbstractEmploymentState
    {
        public TechinicalLeadState(Employee employee) : base(employee)
        {
        }

        public override void Promote()
        {
            // Do Nothing, this is as high as it goes for now.         
        }
 
        public override void Compensate(Accounting accounting)
        {
            accounting.Pay(Employee, 100000);
        }
    }

    public class Accounting
    {
        public void Pay(Employee employee, int dollars)
        {
            // Pay the employee         
        }     
    }

In this example, employees are compensated and promoted based upon their positions. The domain object, Employee, delegates these actions to the AbstractEmploymentState object.

Note how simplified the Promote and Compensate methods of Employee are:

        public void Promote()
        {
            EmploymentState.Promote();
        }

        public void Compensate(Accounting accounting)
        {
            EmploymentState.Compensate(accounting);
        }

Adding a new state, or increasing the complexity of the logic involved in compensation and promotion of the Employees is encapsulated, leaving the design flexible.

Polymorphic Employee

Ok, so polymorphism is good. Every OO programmer knows that, right? So why don't we just make the Employee class polymorphic with subclasses for each position i.e. JuniorDeveloper, SeniorDeveloper, and TechnicalLead are all classes that inherit from Employee and implement the appropriate Compensate and Promote logic.

In this case, implementing the promote logic in the subclasses would be quite challenging as we can not change the type of a class at runtime. It could be done by changing the Promote method signature to return an Employee. The subclasses could then each implement Promote that returned an appropriate subclass of employee. However, this solution feels contrived. It is also more difficult to understand for a future maintenance programmer and could lead to hard to find bugs.

Another reason we may not wish to have a polymoprhic Employee class is because there may be multiple state objects in a single domain object. What if we need not only to compensate and promote employees based upon their position, but also to assign vacation days based upon the project to which the empoloyee is currently assigned? A situation where we needed a class for TechnicalLeadWhoIsWorkingOnProjectX arises.

Another reason to use the state pattern instead of full blown polymoprhism of the domain object is when using an ORM such as NHibernate. NHibernate with Single Table Inheritance does not make it easy to change the type of a persistent object. You can do with with SQL, but it's a clumbsy solution.

Conclusions

The state pattern is a useful tool in a programmer's swiss army knife of design patterns. It can help you avoid ugly switch statements and encapsulate domain logic in a flexible manner.

Data Transfer Objects

Nathan Stott — Sun, 24 Aug 2008 04:08:44 GMT

Data Transfer Objects Pattern

Data Transfer Objects (DTOs) are a necesarry time-sink when working with SOA. Proper SOA dictates that you must not pass domain objects across service boundaries. In many cases, such as when using an ORM, it is extremely difficult to pass your domain objects across the service boundaries even if you choose to disreguard the SOA guidance. Also, there may be good reasons why you do not want to make your domain objects serializable.

DTOs Defined

So what exactly are DTOs? They are objects that have no behavior outside of accessors and mutators of their properties. Often times DTOs line up one-to-one with domain objects as in the following example.


/// <summary> 
/// Domain Object 
/// </summary> 
public class Company
{
    private string name;
    private string taxId;

    public Company(string name, string taxId)
    {
        this.name = name;
        this.taxId = taxId;
    }

    public string Name { get { return name; } }
    public string TaxId { get { return taxId; } }
}

/// <summary> 
/// Data Transfer Object 
/// </summary> 
public class CompanyDTO
{
    public string Name { get; set; }
    public string TaxId { get; set; }
}

Other times DTOs may need to carry data for a request that has no direct representation as a single object in the domain. Consider a service that needs to expose data about a company and its owner. Obviously the clients shouldn't have to request data about the company and then data about the owner in a separate request. Doing so would incur the costs of two round trips, and the owner data is a part of a single logical unit as exposed by the service.


/// <summary> 
/// A company 
/// </summary> 
public class Company
{
    private string name;
    private string taxId;

    public Company(string name, string taxId)
    {
        this.name = name;
        this.taxId = taxId;
    }

    public string Name { get { return name; } }
    public string TaxId { get { return taxId; } }

    public Owner Owner { get; set; }
}

/// <summary> 
/// Owner of a company 
/// </summary> 
public class Owner
{
    public Company Company { get; set; }

    public string FirstName { get; set; }
    public string LastName { get; set; }
}

/// <summary> 
/// Data Transfer Object 
/// </summary> 
public class CompanyDTO
{
    public string Name { get; set; }
    public string TaxId { get; set; }

    public string OwnerName { get; set; }
}

From Domain Object to DTO and Back Again

The assembler pattern, a subset of the mapping pattern, is used to translate DTOs to and from domain objects.

It is possible to create a reusable conventions based assembler. I will talk more about this in the future. For small projects, the cost of creating assemblers for the DTOs is trivial. For larger ones, it is still worth the effort for the sake of encapsulation.


/// <summary> 
/// Assembler for Company and CompanyDTO. 
/// </summary> 
public interface ICompanyAssembler
{
    CompanyDTO Convert(Company company);
    Company Convert(CompanyDTO DTO);
}

What is so useful about an object that has no behavior?

DTOs may seem like weak objects because of their lack of behavior; but this is what makes them the one object that is safe to pass across a service boundary. A client that interacts with your service may, and often will, have a different domain from the service itself. In fact, many different clients with many different domains may interact with your service. It is difficult and undesirable to share the same domain model between a service and all its potential clients.

Consider again the Company example. Let us assume that the service we are writing is a better business bureau catalog of companies. The domain object, Company, may include such methods as "FileComplaint" or "RevokeLicense."

This service may be consumed by an auction site that wants to use the companies names and ratings but has no need to file complaints and does not have the ability to revoke a license. The company domain object for the auction site will include methods such as "AddAuction" or "AssociateWithReview."

Sharing the domain objects between the auction site and the better business bureau service would pollute both domains; not to mention the fact that they may, and in this example certainly would, have different owners who do not wish to share code bases.

Sharing DTOs, because of their lack of behavior, works fine though. The DTOs serve as a simple, abstracted definition for the data that the service and its clients must exchange.

DTOs also insulate your service clients from changes to the domain of the service and vice versa. You are free to change your domain objects as much as you want and leave the DTOs alone. The assembler can simply be updated as the domain objects are updated.

If the domain objects were shared by the clients, every change to a domain object would directly impact clients, greatly increasing the costs of maintaining the service.

MVC Forms WIth Validation Open Sourced

Nathan Stott — Sun, 17 Aug 2008 21:25:30 GMT

I've set up a google code repository here for the ASP.NET MVC Forms With Validation framework I discussed in this post.

I have made some alterations to it since the post that I will review in a later posting.

Briefly, the major changes are as follows:

Multiple fieldsets are now supported in the forms.
I have taken the first steps towards supporting objects that contain child objects. A 1-1 relationship is supported in the current revision. A new fieldset is generated for each child object.
Strategies have been revamped so that they no longer are mapped to types. Now a strategy is allowed to return null if it does not want to handle a property descriptor passed to it. If it returns null, the next strategy in the list will be tried.

Check it out. Tell me what you think. I am accepting patches and if you want to be a contributor, contact me through the contact form on this blog.

Forms Framework with Validation for ASP.NET MVC

Nathan Stott — Sun, 10 Aug 2008 17:08:49 GMT

Update: This project has been open sourced. See details in this post.

Another Update: This article was written using asp.net MVC preview 4. The better option now is to use MVCContrib's validators or the MVCContrib fluent html project in general with IDataErrorInfo. I leave this post here as a reference. Also, if you wish to have a more Django style forms framework, this would be a great starting point. The code is freely available for anyone who wishes to use it.

One thing that is notably missing from ASP.NET MVC is a good way to handle forms and their validation. To resolve this issue, I started on a simple forms framework this weekend.

The end goal

I don't particularly like the action filter to handle the insertion of the model as a parameter. I would prefer it be done via windsor and interceptors; however, for the first go round I have decided to keep the castle stack out of this. The technique could easily be adapted to use MVC Contrib's WindsorControllerFactory and interceptors so that attributes do not have to be on every action you wish to use a form helper with. More on that later.

For those of you who want to skip the reading and get straight to the code, download the sample project. Look at the /Home/Contact page. Note: the sample project depends on MVC Preview 4.

The Components

Field - A field is the smallest unit of input and validation in a form.
Widget - A widget is an abstraction of HTML template text for input.
FormBase - Base class for form helpers.
ModelForm - A form auto created from a POCO model.

Widget

A widget has a name, a value, and some attributes. The name and value properties are by default shortcuts to the name and value attributes of the widget's attribute collection. However, this behavior is overridable in subclasses. A widget also has a way of rendering itself as XHTML.

Field

A field has a name, a value, and a widget. By default a field is required, and it has a publicly exposed validate method so that it can be asked to validate its value. It also has the ability to output itself as XHTML.

FormBase

FormBase, the base class for forms contains a collection of fields, a method to validate the fields, and a method to load the values of fields from a name value collection. The latter facilitates the loading of data from a browser request.

The first concrete implementation of FormBase I created was ModelForm. A ModelForm accepts a generic type argument and in its constructor takes an object of that type. It uses this object to generate fields for the form. The generation logic is implemented using the strategy pattern so that it is easily customizable.

Here is the strategy interface

The ModelForm registers default strategies

The constructor allows you to pass in your own strategies

With that, we have everything we need to make a form from a POCO.

Model Action Filter

One of the neatest things ASP.NET MVC does is allow you to make controllers with parameters that will be filled in from the request.

I wanted to be able to do this with my form classes as well.

For the first go round, I decided not to use what I would prefer: Windsor and IInterceptors. Instead I integrated the MVC way by using their action filters.

The filters give us everything we need to set the values for a parameter. We have access to the parameters through the ActionMethod.GetParmaeters() method and we can set the parameters via the ActionParameters dictionary.

Here is the action filter

FormFactory is a simple helper class that uses a strategy pattern to create forms based upon the type passed in and a NameValueCollection.

Settings filterContext.Action

Now, this action will work!

Rendering the Form in a View

I provided three canonical methods for rendering the form:

AsDiv - renders the form with each field wrapped in a div
AsTable - render the form with each field as a table row
AsList - render the form with each field as a list item of an unordered list

I also provided a AsCustom method that allows you to specify an XElement to wrap the form fields inside of and an XElement to use as the parent for the children generated by the field instances.

If you want even more flexibility, the rendering is completely overridable by subclassing.

Rendering the form is as simple as passing it to a view and calling AsDiv() or your preferred alternative.

All output is valid XHTML. Invalid fields receive an error class.

Rendered

Validation

Download the Sample Project
Note: the sample project depends on MVC Preview 4.

Building NHibernate From Source

Nathan Stott — Mon, 04 Aug 2008 13:13:57 GMT

Recently, on nhusers, the NHibernate users mailing list, I've seen questions from people wishing to get started building NHibernate from source. Some people are unfamiliar with open source in the .NET world and the tools used for it, so I made this beginner level screencast about how to get started building NHibernate from source.

You can download the screencast here.

Here is a list of the prerequisites you will need to follow along:

For reference, you can find the official NHibernate document about getting started from source here.

Note: I realized after I posted this that I forgot to provide a link to the free codec needed to view this screencast. You will need to d/l the free camstudio lossless codec (here) to view this video. Extract the files, right click on the .inf, and select install. You will receive a warning, but it's ok. This is a widely used screencasting codec and you can find a lot of info about it via google.
In the future, I'm going to convert my videos to flash and stream them to make things easier all-around.
Sorry for the inconveniance.