In my development process I do use what Rob is describing in his post “Crazy Talk: Reducing ORM Friction” with some slight differences.
For example I developed Tech Head Brothers portal this way, as Innoveo Solutions web site. I use TDD and Domain Driven Development and I keep the mapping as one of the last step for my implementation.
I do have a generic Repository interface as following:
using System;
using System.Collections.Generic;
using System.Linq;
namespace TechHeadBrothers.Portal.Infrastructure.Interfaces
{
/// <summary>
/// IRepository exposes all methods to access the data repository
/// </summary>
public interface IRepository
{
void InitializeRepository();
bool Save<T>(T entity) where T : class;
bool SaveAll<T>(IList<T> entities) where T : class;
bool Delete<T>(string id) where T : class;
T Find<T>(string id) where T : class;
IQueryable<T> Find<T>();
IQueryable<T> DetachedFind<T>();
IQueryable<T> Find<T>(System.Linq.Expressions.Expression<Func<T, bool>> expression);
int Count<T>();
int Count<T>(System.Linq.Expressions.Expression<Func<T, bool>> expression);
}
}
My ORM mapping tool of choice is Euss. And here comes the slight difference, I do have one implementation of my interface leveraging Euss, and that’s it. All different possibilities are handled by Euss. During my work on the definition of the domain I took the habit to use an Euss XML Engine or an Euss Memory Engine. I use those two engine for my unit test and my real application.
Following the lean principle I postpone the choice of the data repository till the last minute, when I know more about the real need. So it really happen that I stay with an XML Engine so that all my data are stored in an XML file. If I need more I go to an Euss SQL Mapper Engine and then define the mapping.
So I moved to the ORM framework the different implementations.
Now I am still free to go to another ORM, or something else, by using the interface IRepository.
I used several time this technique and I am currently happy about it.