Understanding the Repository pattern

For each type of object that needs global access, create an object that can provide the
illusion of an in-memory collection of all objects of that type. Set up access through a
well-known global interface. Provide methods to add and remove objects, which will
encapsulate the actual insertion or removal of data in the data store. Provide methods
that select objects based on some criteria and return fully instantiated objects or
collections of objects whose attribute values meet the criteria, thereby encapsulating
the actual storage and query technology (…)

Evans, Eric (2003) Domain Driven Design - Tackling Complexity in the Heart of Software

The above quotation gives an overview of the main concept of the responsibility attributed to the repository pattern. Oversimplifying maybe, a repository is a mechanism of dealing with the lifecycle of an entity (or aggregate root) - providing a clear, centralized interface to access, modify, or destroy it.

One of the main reasons to use a repository is to clearly decouple the persistence logic from the model and application layers. A repository isn’t a DAO, it contains business logic of how each type of object in your model can be dealt with, it might even use a DAO implementation behind the scenes to do the actual queries. It also will most likely make use of factories to create the fully instantiated entities, once the necessary data has been retrieved from the database.

Henceforth, while developing the application and model layers, the developer can focus his energy on the domain itself, since the entire persistence concern has been delegated to the repositories.

Any big enough application in which you are not planning on using a full fledged persistence framework will most likely have some sort of implementation of a repository. Otherwise the domain would be very polluted with infra-structure and persistence logic. So, the idea here is to show an implementation of this pattern that is been working quite well for us in a real business scenario - since it might help other people too, if they happen to be working on a similar platform.

Implementing the Repository

Okay, this is going to be very specific. On our current projects, for various reasons, we’re using the following platform:

• Language: Microsoft .NET Framework 3.5 SP1 (C#)
• Database: Microsoft SQL Server 2005
• IDE: Microsoft Visual Studio 2008 Team System
• Source Control: Git

On a given point during a sprint a couple of months ago, one of my teammates (kitaly) came up with an example of a repository implementation which seemed to be going to a very interesting direction. So, on our first all new project after that, we’ve decided to try and check it out if we could make it work for our business scenario.

The main idea was to provide the methods: "save", "find" and "delete". To gain that, each specific repository would have to implement as few as possible methods, for data mapping, generating custom fields and eventually logic for business access constraints.

Even if our brand new application had a pretty good expertly crafted database, some parts of it still had to deal with the legacy tables. So, we’ve chosen to go with LINQ to SQL, since it is very close to doing pure SQL (but not quite), and gave us all the flexibility (and customizability for performance) we shall need. After a incredibly productive and rather enjoyable session of massive brainstorming we’ve managed to do a working demo.

After being amused for its elegant and succinct implementation and seeing it working well on production environment, I’ve decided to dedicate some time to improve it even more, providing more functionality "out of the box", therefore requiring less code on each specific repository.

There is, although, a slightly upsetting tradeoff we had to take while developing the repository. Since LINQ relies on expressions going straight to queries, we’ve decided to expose the actual auto built DTO objects from LINQ’s data context. The problem here is that we broke one of the main tenants of the repository pattern: decoupling with the database. What we gained though was tons of flexibility and quite less code if we think what the same functionality would take if it was done using some sort of query object implementation. After all, programming is just about trade offs, and picking the ones that are better for your specific case. That’s why technical books can never be read as recipes, but sources of knowledge base.

Enough with small talk, time to see some actual code. Please note that I won’t post written code here (just pictures, since they are a lot easier to manage) - but don’t worry, you can download the entire solution on github, which includes the repository implementation and an extra project with a very easy to get example of usage.

For the forthcoming sections I’ll assume you have a good understanding of the C# language, its functional constructs, lambda expressions, and template (aka Generics) implementations - besides solid OO concepts, of course.

The heart of this repository implementation is its main interface:

The idea here is pretty simple:

• Call "Find" passing an expression to get whichever entries you want. Note that you are going to refer to the DTO on the expression, but you are going to get a list of your model given entity or aggregate root. For the sake of keeping the repository’s client code as simple as possible, there are methods to find a list of records and a single specific record. If you try to call "FindSingle" with a condition that matches more than one entry on your database an exception will be thrown.
• Call "Save" passing an entity to persist it. If it isn’t already on the database, it’s going to be created, otherwise the existing entry will be updated. Note that you can also pass an optional transaction to control transactions - in this case, the operation will occur inside the transaction, and you can commit or rollback it later.
• Call "Delete" to remove an entity from the database. Note that similarly to the "Save" method, you can pass an optional transaction to handle transactions.
• The repository is defined using two template parameters (I know it should be called Generics in C#, but I got so used to call it Template back in the C++ days…): the "TRow" should be mapped to a LINQ DTO, while the "TEntity" should be mapped to an entity of your model.

The repository project defines a basic abstract implementation of this interface, so that, if you have a decent enough database (each entity mapped to a table) you gain some pretty nice functionality out of the box. I’m not going to get into the details of the basic repository implementation since it’s meant to just be used as is.

What’s next is an example of what you would need to do to create a repository specific for one of the entities on your model:

I Believe that the "BeforeSave" and "AfterSave" methods should be self explanatory. But the "FindEntity" probably is not - the idea behind it is to establish a way to find the specific record that represents an in memory model entity on the database - so that the "Save" and "Delete" template methods can do their jobs.

An example of how to actually use the repository shall be worth a couple thousand words, so there it goes: Please note that the code shown above is just for the sake of exemplifying what can be accomplished with the proposed repository implementation - I mean, don’t ever write unit tests like that on your projects, each unit test should test one specific piece of functionality.

And that’s pretty much it, feel free to download the source code on github and check the whole sample usage project (including all the snippets used in this article).

Feel free to criticize and leave your remarks on the commentaries - we’d love to hear your opinion.