Repository Pattern – The Single Source of Truth

 

Repository Pattern – The Single Source of Truth

Architecture plays a crucial role in any software development process. If you want to build a more robust, reusable, testable, and re-configurable system, you have to invest heavily in designing the architecture.

What Does “Architecture” Mean?
By definition: An architectural pattern is a general and reusable solution to a commonly occurring problem in software architecture within a given context. Architectural patterns are similar to software design pattern but have a broader scope.

You may be familiar with popular patterns like MVC, MVP, Client-server, Event-based, Layered pattern, etc. Each have defining building blocks that compose the structure and nature of any particular architecture, as listed below:

Presentation layer (also known as UI layer)

Application layer (also known as service layer)

Business logic layer (also known as domain layer)

Data access layer (also known as persistence layer)



This diagram represents the basic 3-tiers architecture design, where every layer operates separately, according to their purpose, functionality, scope, and computation. This is a general approach for any system design, but it can vary for each technology and requirement for the scope.

 

The Repository Pattern: Where and When it Comes into Play

The Repository contains the set of objects in a data store and the operations performed over them. It provides a more object-oriented view of the persistence layer. It also supports a clean separation and one-way dependency between the domain and data mapping layers.

A few things to note:

1:  Providing a more object-oriented view of the persistence layer means the repository fits somewhere between application and presentation layer.


2:  The repository provides an abstraction for the presentation layer, where your data access layer will be loosely coupled with it. This means the application.This means the application
layer never depends on the data origin. view of the persistence layer means the repository fits somewhere between application and presentation layer.


3: You can divide and map different data layers with the help of the repository. This helps to modularize your application where all modules are more reusable, testable and configurable..

 

Repository in Action: Use Case

A publishing company aggregates news from multiple sources and provides the user a seamless one-stop experience. The breakdown looks like this:

Presentation layer – provides user interface for reading the news
Application layer –
fetches news from different sources
Data layer –
shows news sources

If there’s  a change in the news source from a tech module, the application layer needs to change the logic to fetch data from other sources and pass it to the presentation layer. If we introduce a repository in between these layers, the application layer now only needs to change the source configuration (assuming the data layer follows a common specification for news data.)



The repository is responsible for data mapping and persistence where the application layer has gaps in the HOW and FROM WHERE the data is coming. Technically, it works as an abstraction layer like this:

class NewsRepository implements Repository<News> {
  public  @Override
    public List<News> query(Configuration configuration) {
		// query news data and map into presentable object.
}
}

Per the configuration/specification provided to the repository, it needs to resolve the required source and query/map the data which will be passed to the business logic layer. This will then operate on the data for the presentation layer.


Repository & Mobile App Development

Mobile Apps  are typically responsible for providing a seamless user experience where it might need some time to persist data at the mobile end. But the mobile app is not always tied to a large system like web or cloud. Apps sometimes have to perform dual responsibility of presentation and application layer. So repository plays an important role:



For example,  following MVVM(Model-View-View-Model) architecture, ViewModel acts as an application/business logic layer. Utilizing the repository, you can provide an abstraction layer for ViewModel in which repository  fetches data from the network, local database, or cache, depending upon the configuration provided.

The idea behind all this is that the data origin is transparent for the client (presentation layer). It doesn’t matter if the data is coming from a database or the cloud. The only truth is that data is available to deliver to users.



A Minimalist Approach

Architecture should be lean, enabling the reuse or reconfiguration of modules.  Unnecessary creation of repositories increases overall complexity and dependencies, undermining the purpose of adopting a design pattern. Also, implementation sometimes depends highly on the underlying technology which might increase the overhead in the development cycles.

Stay-Up-To-Date

Keep in the loop with the latest in emerging technology and Mutual Mobile