Writing a repository class

Persistence has been a hot topic in software development for a long time. The main problem is that the most popular approach for software development these days, Object-Orientation, doesn’t really map easily to efficient external storage systems like relational or even noSQL databases.

The technical limitations were mostly solved with some object mapping tools(ORM) like NHibernate or Entity Framework that make persisting and querying objects a breeze for most scenarios. The problem then became how do we integrate the act of persisting and retrieving objects with our Domain Model and, more important, our Ubiquitous Language.

A good way to integrate persistence needs and the Ubiquitous Language is using what is known as Repositories. In his Domain Driven Design book, Eric Evans defines the Repository pattern as “A mechanism for encapsulating storage, retrieval, and search behaviour which emulates a collection of objects”.

Naming as a solution

The concept of a Repository as a list of objects is not too hard to understand but it is very common for those classes to end up with methods that are not related to lists at all. A lot of repository implementations I have written before suffered this problem. Until I found this blog post by Phil Calçado. He states hat the best way to make people remember that Repositories are not DAO-like classes starts with how you name them.

Instead of the more common naming style displayed below:

   1:  class OrderRepository {

   2:     List<Order> GetOrdersFor(Account account){...}

   3:  }

You should use:

   1:  class AllOrders {

   2:     List<Order> BelongingTo(Account account){...}

   3:  }

At first I find it strange that such a small change will make any difference but it really helps a lot. As an example, let’s look at two repositories that contain methods that don’t belong to them. Which one do you think it’s easier to identify as problematic?

   1:  //classic naming style

   2:  class UserRepository{

   3:   User RetrieveUserByLogin(String login){...}

   4:   void SubmitOrder(Order order){...}

   5:  }

   6:   

   7:  //client code

   8:  User u = userRepository.RetrieveUserByLogin(“billgates”);

   9:  userRepository.SubmitOrder(new Order()); 

  10:   

  11:  //new naming style

  12:  class AllUsers{

  13:   User WithLogin(String login){...}

  14:   void SubmitOrder(Order order){...}

  15:  }

  16:   

  17:  //client code

  18:  User u = allusers.WithLogin(“billgates”);

  19:  allusers.SubmitOrder(new Order());

Keep in mind that the language you use does impact how you think (Sapir-Whorf works for programming). Methods that start with retrieve, list of get are often bad smells.