Repository Design Pattern Demystified

What is the Repository Design Pattern?

To put it simply, it is an implementation of a brokering layer between the application and a data source. Neither party needs to be be aware of the other to perform their respective jobs which allows us to have a decoupled architecture which in turn helps in the scaling of the application in the big leagues without having hard dependencies.

Why should you care?

Let us understand this with an example. Imagine we are building an online store which sells orange flavored candies. It’s a small store and it keeps local inventory, so we don’t need anything fancy here. The storefront application can just hook into the database and take orders online based on how much inventory is at hand. This will work fine since the store has only one supply warehouse and has a limited area of operation. But what will happen if this store wants to expand its area of operation? The store might want to expand into another city or across the country and having a central inventory system would be so cumbersome.

Now if we are still using data models then we have a somewhat tightly coupled application. The storefront application needs to be aware of every data source it has to interact with and that is a poor application design. The job of the storefront application here is to allow customers to place orders for the candy, the application should not be concerned about the data source, it should not have to keep track of all the different data sources. This is where data repositories come in to play. Per the Repository Design Pattern, a public API is exposed via an interface and every consumer (our storefront application in this case) uses that API to talk to the data source. Which data source is being used or how its being connected to, these are not of concern to the application. The application is only concerned with the data it gets and the data it sends to be saved.

Once the Repository Design Pattern is implemented, repositories can be created for each data source. The storefront application no longer would need to keep track of any data source, it just uses the repository API to get the data it needs.

Is it the magic bullet?

Well, no it is not. Like every design pattern it has its ups and downs, pros and cons.

Pros:

• Separation of concerns; the application need not know about or track any or all data sources.


• Allows easy unit testing as the repositories are bound to interfaces which are injected into classes at run time.


• DRY (Dont Repeat Yourself) design, the code to query and fetch data from data source(s) is not repeated.

Continue reading %Repository Design Pattern Demystified%

more