I find in retrospect I was more focused on the the data organization and persistence as apposed to the rules of the domain. More and more the physical data of the systems I am working on does not map perfectly into how I want to manipulate it or even think about it conceptually, so I have moved towards DDD and using a Domain Model.

Background

I have been refactoring an existing application iteratively through unit tests. I mapped the existing business logic layer classes to interfaces containing just their properties. I then could create new domain model classes around those interfaces and compare results apples to apples in my unit tests. Eventually the interfaces for the model will be removed once the domain services and domain repositories are done and tested.

The existing system is stored procedure based with the Enterprise Library. While a great tool in its day I have since moved on to greener pastures with LINQ-to-SQL. (I may try out nHibernate soon as people seem to love it). The current approach is to use the existing stored procedures with LINQ-to-SQL, which it turns out works really well.

You can read more about how I began migrating the existing code base in my previous blog, Unit Testing DAL Migration from Enterprise Library to Linq-to-Sql.

The Point

What I need in my repositories is a way to map the generated LINQ-to-SQL entities into my domain model. I start with a way to map one individual item from the physical system to the domain model.

A previous revision had this as a class method in the repository but I wanted to reuse it generically across multiple repositories. Next it was in the Repository base class, but decided against “polluting” the abstract base class with the details of what its children were doing; it just houses the DataContext and exposes basic methods like Save() which calls SubmitChanges().

The next step was to move it out into an interface that each repository can implement with its specific details.

public interface IMapper<TModel, TPhysical> 
{
    TModel MapToModel(TPhysical item);
}

Next I needed a way to map a collection of the physical entities into a list of domain models. I used an extension method on the IMapper interface to isolate the functionality of mapping to one logical unit, the IMapper interface.

public static class IMapperExtensions
{
    public static IEnumerable<TModel> MapToModel<TModel, TPhysical>(
        this IMapper<TModel, TPhysical> mapper, // extend the interface
        IEnumerable<TPhysical> source) // list of physical entities
        {
            foreach (var item in source)
            {
                // return the mapping of the item 
                // through the interface and its implementation
                yield return mapper.MapToModel(item);
            }
        }
    }
}

Putting it Together

Below is a final look at a Repository created with the approach.

// where IFoo is the interface I extracted from the existing BLL
// and Foos is the LINQ-to-SQL entity type
public class FooRepository : Repository, IMapper<IFoo, Foos>
{
    public IList<IFoo> GetList()
    {
        var query = db.usp_Foo_Select();
        return this.MapToModel(query).ToList();
    }

    public IFoo MapToModel(Foos item)
    {
        // create the domain model implementation
        return new Foo() 
        {
            FooID = item.FooID,
            Name = item.Name
        };
    }
}

Closing Thoughts

I like working with an object set that isn’t “tied” to the physical implementation. I can shape the object the way that makes best sense to the domain while still tailoring the physical storage of the data for performance.

Getting Started

In order to make sure I didn’t break any existing functionality I used unit tests (MS Test) to compare the existing and ported code.

[TestMethod]
public void SelectFoos_Present_ResultsMatch()
{
    Assert.Fail();
}

Setup

With this test in place copied FooDAL to a new directory in the DataAccessLayer namepsace called Linq.  I then swapped out the base class containing the Enterprise Library factory code with a new LinqDal class that contained my FooBarDataContext.  In my new Linq-to-SQL dbml file I mapped the Foo table and the Foo_Select stored procedure, setting the return type to the class for the table.

The main focus was making sure the results were identical between the two implementations.  The risk would only increase as I went through and refactored the code base.

Revision 1

[TestMethod]
public void SelectFoos_Present_ResultsMatch()
{
    var entDal = new FooDAL();
    var entResults = entDal.SelectFoos();

    var linqDal = new Linq.FooDAL();
    var linqResults = linqDal.SelectFoos();

    // ... compare
    Assert.Fail();
}

Comparing Results

In order to compare the results I deferred to my trusty copy of More Effective C# by Bill Wagner.

using (var firstSequence = entResults.GetEnumerator())
using (var secondSequence = linqResults.GetEnumerator())
{
    while (firstSequence.MoveNext() && secondSequence.MoveNext())
    {
        var firstItem = firstSequence.Current;
        var secondItem = secondSequence.Current;

        Assert.AreEqual(
            firstItem.FooID, 
            secondItem.FooID, 
            firstItem.FooID + " - " + secondItem.FoodID);
    }
}

This made sure the sequencing of the objects was the same, but what about making sure the objects were correctly populated?

EqualityComparer

I didn’t want to mess around with the existing business class that is returned by the DAL method so instead I used another tip from Bill Wagner’s book; EqualityComparer.

private class FooComparer : EqualityComparer<FooBLL>
{
    public override bool Equals(FooBLL x, FooBLL y)
    {
      	return x.FooID.Equals(y.FooID) &&
            	x.Name.Equals(y.Name);
    }

    public override int GetHashCode(FooBLL obj)
    {
      	return EqualityComparer<FooBLL>.Default.GetHashCode(obj);
    }
}

Final Revision

With this in place I could factor out the comparing logic into a separate method in a base class and reuse it for the different DAL classes I had to migrate. The final test looks like this:

[TestMethod]
public void SelectFoos_Present_ResultsMatch()
{
    var entResults = new FooDAL().SelectFoos();
    var linqResults = new Linq.FooDAL().SelectFoos();
            
    this.CompareLists<FooBLL>(entResults, linqResults, 
        new FooComparer());
}

// in Test base class
public void CompareLists<T>(IEnumerable<T> first, IEnumerable<T> second, 
    EqualityComparer<T> comparer)
{
    using (var firstSequence = first.GetEnumerator())
    using (var secondSequence = second.GetEnumerator())
    {
        while (firstSequence.MoveNext() && secondSequence.MoveNext())
        {
            var firstItem = firstSequence.Current;
            var secondItem = secondSequence.Current;

            Assert.IsTrue(comparer.Equals(firstItem, secondItem));
        }
    }
}

Closing Thoughts

I refactored 7 DAL classes using this and I feel pretty confident the results are exactly the same. I did run into some cases where writing the tests did reveal discrepancies in the results so I feel it was time well spent.

The only change I made looking back was overloading the ToString method on FooBLL so I could see what the differences were in the test results. The message for the Assert called ToString on the objects giving me an xml visualization of the class so I can track down the error.

public override string ToString()
{
    var serializer = new 
        System.Xml.Serialization.XmlSerializer(this.GetType());
    var writer = new System.IO.StringWriter();
    
    serializer.Serialize(writer, this);
    return writer.ToString();
}

ASP.NET MVC

• Architecture – Los Techies
• Fluent HTML – Tim Scott
• Unit Testing Controllers – Jeffrey Palermo
• Validation of Variable Length Lists – Tim Scott
• Validation of ModelState with MvcContrib’s Fluent HTML Helpers
• View Models – Los Techies

C#

• Balance HTML Tags – Jeff Atwood
• Strip HTML Tags – Roy Osherove

DDD

• Terms
• Aggregates & Repositories
• Hexagonal Architecture – Alistair Cockburn
• Onion Architecture – Jeffrey Palermo
• Anemic Domain Models – Stack Overflow
• Linq to Sql, Interfaces and the Repository Pattern
• DDD Infrastructure Services –  Stack Overflow

Dependency Injection

• Structure Map

JQuery

• JTemplates – JQuery Plugins
• JTemplates Example

LINQ-to-SQL

• 10 Tips to Improve your LINQ to SQL Application Performance

Logging

• ELMAH – Home
• ELMAH – MSDN

Mocking

• NMock
• Comparing Moq to Rhino Mocks – Phil Haack
• Rhino Mocks Stubs

Routing (WebForms)

• ASP.NET Routing… Goodbye URL rewriting? – Chris Cavanagh
• Using Routing With WebForms – Phil Haack

Silverlight

• Silverlight Prism – Erik Mork (Video)
• Development Guides – Erik Mork
• Silverlight 3 as a Desktop Application

WCF

• Hosting and Consuming WCF Services – MSDN

WebForms

• Validation – Adding Messages to Validation Summary