service-repository pattern

There are many articles about the service-repository pattern online, but they often jump straight into code, leaving many people confused. The code examples are mostly CRUD operations, so it’s even harder to grasp the benefits of this pattern. When it comes time to implement it themselves, people don’t know where to write specific pieces of code. That’s why this article exists.

Imagine that our application is a company. The service-repository pattern can be illustrated as follows:

  • Controller is the director.
  • Service is the department manager.
  • Repository is the clerk.

Controller

At first, the company is small. The director wants to reward employees, so they directly use Excel to fetch the employee list. At this stage, the director’s (Controller’s) responsibilities are overwhelming—they have to decide which employees to reward (business logic) and manage the Excel files (data access).

Controller => Database

Repository

Later, the company prospers, just like when our application grows. The director hires a clerk (Repository) to handle Excel tasks. The director instructs the clerk to print an employee list for rewards.

Now, the director focuses only on the business task (deciding which employees to reward). They DON’T need to know how the clerk names the columns, where the employee list is stored (Excel, Google Sheets, database, text file, API, etc.). The director simply needs to say, “Get me the employee list,” and the clerk delivers (of course, according to the specified format, which we’ll cover in another article).

Repository acts as a middle layer between business logic and data access (like the clerk intermediating between the director and the Excel file).

Controller => Repository => Database

Service

As time passes, the company grows even larger. The director becomes overwhelmed with work, even though the clerk handles Excel-related tasks. The director’s business responsibilities are still too many.

The company is divided into departments, and department managers (Services) are hired, each specializing in a specific area. For example, there’s an HR manager, a marketing manager, and a sales manager.

The director tells the HR manager: “Handle employee rewards for me.” The HR manager (Service) instructs the clerk to generate the employee list to manage the rewards.

The director (Controller) DOESN’T need to know how the HR manager decides on the rewards. Similarly, the HR manager (Service) DOESN’T need to know where or how the clerk stores the employee list.

At this stage:

Controller => Service => Repository => database

  • The HR manager only handles HR-related tasks. This means a company can have multiple managers (Services).
  • Some tasks require the director to call on multiple managers to collaborate.
  • How the clerk stores the employee list or names the columns in Excel doesn’t affect the HR manager. This means we must code in such a way that changing a column name in the database doesn’t require modifying business logic in the Service.