The Repository Pattern

I'm not sure if Martin Fowler conceptualized the repository pattern, but his book Patterns of Enterprise Application Architecture (PoEAA) is where I first came across the definition:

"Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects."

He has very carefully selected his words. I have my own definition. Consider it the layman's version:

"Separates data from its source." 

Let's dig into an example.

The Repository Pattern in .NET

Every .NET programmer has written some sort of code that accesses a database or web service and returns something. Traditionally, the ever-present n-tier/three-tier philosophy dictates that the code for that should be in its own package/layer, the data access layer. What that philosophy does not dictate is the method signature and the return type; they're extremely important. Let's look at your traditional DAL:

	public class PeopleDAL
	{
	public DataSet Person_GetAll()
	{
	//Returns a DataSet containing all people records in the database.
	}
	public DataSet Person_GetByPersonID(int personID)
	{
	// Queries the database for the particular user identified by
	// personID. If the user is located then the DataSet contains a
	// single record corresponding to the requested user. If the user
	// is not found then the DataSet does not contain any records.
	}
	public bool Person_Save(ref int personID, string fname, string lname, DateTime dob)
	{
	// Locates the record for the given personID. If the record exists,
	// the method updates the record. If the record does not exist, the
	// method adds the record and sets the personID variable equal to
	// the identity value assigned to the new record. Then the method
	// returns the value to the business layer because personID is
	// marked with the ref modifier.
	}
	public int Person_DeleteInactive()
	{
	//Deletes all inactive people in the database and returns a value
	//indicating how many records were deleted.
	}
	}

view raw classic-DAL.cs hosted with ❤ by GitHub

What will the dev on this project do if the People DB gets outsourced and is now accessed via webservice? Convert the web service return into datasets, or change all the business layer classes to work with whatever the new return is? Or, what if they change to a db that doesnt easily convert into datasets? Not a great position to be in... Why not change it to something more generic that will never change?...

Here's a look at the repository pattern implementation:

	public class PeopleRepository
	{
	public List<PersonDTO> Get()
	{
	//return a list of person data transfer objects here
	}
	public void Insert(PersonDTO person)
	{
	//insert a person here
	}
	public void Update(PersonDTO person)
	{
	//update a person here
	}
	public void Delete(PersonDTO person)
	{
	//guess
	}
	}

view raw PeopleRepository.cs hosted with ❤ by GitHub

Notice how this implementation could survive through any sort of data source change because it is using "a collection-like interface"? Much more maintainable.

The Repository Pattern in JavaScript

JavaScript's implementation would need to take into account the fact that AJAX requests (or all node.js functions) are meant to happen asynchronously. In order to allow for this, all we really need to do is implement the callback pattern, which really just boils down to passing an extra function.

	function PeopleRepository() {
	//when using constructor functions like this one to create objects in js,
	//always make sure you're doing so with the new keyword
	//or the scope will be off
	//
	//like so:
	if(!(this instanceof PeopleRepository) {
	return new PeopleRepository();
	//we just enforced new
	}
	//create a get function on the member
	this.Get=function(callback) {
	$.getJSON("some url",callback);
	};
	}
	//instance the repo like so (of course using new)
	var repo = new PeopleRepository();
	//call a get
	repo.Get(function(data) {
	//we could do something with the data that gets returned here
	});

view raw PeopleRepository.js hosted with ❤ by GitHub

That's it!