The Repository Pattern

If you're still writing SQL statements to persist your objects to/from your database, STOP!!! If you fall into this category, your code is likely unreadable by anyone other than yourself. And before you know it, even you won't be able to read your own code. Believe me, I know because I have felt this pain.

In my experience, about 9/10 of database-driven applications could be vastly simplified by using a software pattern known as Repository.

public interface IRepository<T>
{
    T Get(object id);
    void Save(T value);
    void Update(T value);
    void Delete(T value);
    IList<T> GetAll();
}

That's all there is to it. By using this interface as a gateway for getting objects to/from your database, you're able to completely decouple your system from the data access layer (DAL, for short). The advantages to this approach are twofold:

• Your code is 500% more readable because the reader doesn't even have to THINK about the implementation details of your DAL.
• You're able to easily swap out the DAL for a different implementation.

The implementation of the Repository pattern should be capable of reading the type of the object passed to it and then know how to fit the object into the database. Now, I suppose you could write a whole crapload of SQL to implement this interface OR you could use an ORM. I've found that NHibernate is a great way to implement the Repository pattern and that's what I'll be covering in my next blog post.

Update: Here is the next blog post on Implementing the Repository Pattern with NHibernate.