Over the years I have had a number of conversations with other developers that have gone along the lines of
” you should totally check out
And my reaction has always been a resounding “meh”. It’s not that I have no interest in the differences between the many frameworks that are out there; it’s just that when you get right down to it, I shouldn’t HAVE to care. From the point of view of my code, the only thing I should demand of my DAL is that when I ask it for something, it provides; when I ask it to update something, said thing is duly updated. The specific implementation details should have no bearing on any other aspect of what I am writing.
Whenever I set out on a new project, the DAL is generally an afterthought: “oh, and I guess I’ll need to store this data somewhere”. There are,admittedly, some scenarios when the means of storing the data is germaine to the design of the application, but in general if i can query and I can CRUD then I don’t really care how that gets implemented. What I really want is a simple repository pattern, maybe coupled with a unit of work pattern to handle transactions:
public interface IRepository<TEntity> : IDisposable
where TEntity : class
{
IQueryable<TEntity> FindAll();
void Add(TEntity newEntity);
void Remove(TEntity toRemove);
}
public interface IUnitOfWork<TEntity> : IDisposable
where TEntity : class
{
IRepository<TEntity> Repository { get; }
void Commit();
}Once I have defined that interface, the rest of my application should be able to use it without ever knowing whether I am getting the data using the latest entity framework, in-memory data sets or a flat file; it should just be able to rely on it performing as expected.
Taking this view a step further, I should really be able to swap out different DAL implementations whenever I feel like it; EF not performing well in a specific scenario? fine, let’s change to stored procedures. My application should not even notice the difference.
I have worked on projects in the past where we made the decision to change the DAL implementation after we already had a product in place, and the effort that we went through was far more than it ever should have been because the code made assumptions about how the data was stored right up to a UI level. Had the repository been abstracted out behind an interface we could have been done in a few days instead if weeks.
What I am getting at is that choosing your ORM shouldn’t matter, as long as the code is written in a manner that means you can change it later. Who cares if you chose to use EF Code First because it is new and interesting - provided that you can fulfil your repository interface through another means then it really doesnt matter.
I suppose that this really translates into a rant about keeping everything decoupled, but it still bears repeating - the DAL DOESN’T MATTER.