Repository pattern, done right

The repository pattern has been discussed a lot lately. Especially about it’s usefulness since the introduction of OR/M libraries. This post (which is the third in a series about the data layer) aims to explain why it’s still a great choice.

Continue reading “Repository pattern, done right”

TodoApp – Part 3: Fix that data source.

Let’s continue with the refactoring. What are the main window really doing?? Well.

  1. Displaying todo list
  2. Loading and saving stuff to the database

That’s one thing too much. We’ll implement a Repository. imho, Fowler is wrong in his explanation. The most important goal with the Repository pattern is the following line: “Repository also supports the objective of achieving a clean separation and one-way dependency between the domain and data mapping layers”. That’s what the pattern is all about, period. We do not want our domain to have any knowledge about the data source.

In later versions, the data source will be a REST web service publishing stuff as JSON. By implementing a Repository now, we get the bonus that we do not have to do that many modifications in later versions. All we need to do is to switch implementation class from one to another (since we are using an interface and not a class in our code).

The new class is called ItemRepository. The application is a bit more readable now than the first version, right?