Why Repositories Matter!

I recently read a blog titled “Architecting in the pit of doom: The evils of the repository abstraction layer”. In it Ayende makes some pretty compelling points as to why you should not use repositories.  In his example he is stating that NHibernate’s ISession and Entity Framework’s Context objects are repositories.  He also states that we should stop trying to abstract out the data source (stop trying to develop as if we are going to switch out databases).  When you have a single data source this may work.

I wanted to comment but decided that a post would be better. I can expand on my thought as to why repositories work.  The first comment that I want to make is problem should dictate the architecture.  To make a blanked statement that repositories are bad may close the door on certain solutions.  In some instances implementing repositories may over architect the solution but is some instances it may be the right thing to do.

I am working on a side project where I have implemented repositories.  I chose this solution because I have two different data sources.  I have data in a database and I am also using the Netflix OData Service. The repositories allow me to abstract out the OData calls.  My business layer can now work it a MovieRepository (data from OData) and a repository that gets data from my database.  The business layer can then aggregate the data from the two sources and pass it to the Presentation layer.

Through the Specification Pattern I can pass my queries to the repositories and not litter my BLL with data access specific code.  The other thing that I was able to do was to create a database table that had a sampling of the OData data.  I built a repository around that since it adheres to the interface for the OData repository, I can switch them out without a code chance.  I use Unity to inject the repositories into the business layer so switch is as easy as changing the config file.  Now I have a data set to work with in situations where the OData service is not available. 

Repositories also allow me to go to one place to modify my data access code.  The key to using repositories is to have a good infrastructure in place in order to facilitate ease of development.  With right pieces in place adding functionality to an application should take no additional time.  A team from Microsoft – Spain put together the Domain Oriented N-Layered .NET 4.0 Sample App.  This is a great example of the use of Repository and Specification patterns.

Conclusion

The problem with patterns is we tend to over use them or adjust the situation to fit them.  The real skill of the developer is to know how to adapt them to the situation so that they become part of the solution and not part of the problem.