What Is the Repository Pattern in Magento 2?

A lot of articles can be found out there describing repository design patterns, but not all are necessarily clear in the explanation. The description varies from one programming language to another, so it can get confusing sometimes.

Here, we’ll try to begin with the basics, explaining how applications are layered, what a repository is and introduce the repository pattern. Then we’ll talk about how it was implemented in Magento 2 and what does it mean for users of this platform.

Layered Application Design

Let’s suppose you have any application. It could be a web application, a multimedia application, and so on. Applications are usually conceptually divided into layers, not only for better understanding but also for better design and to make the developers’ life easier.

No matter what type your application is, it most likely has to interact with some sort of persistent data. It could be in the form of a hard drive, a network, the cloud, or some other form. This is called the data source. The application also has a presentation layer, which is responsible for end-user interaction and displaying all relevant information.

Underneath the presentation layer is the business layer. This layer is also sometimes called business logic or domain logic. Essentially, it is responsible for translating the real-world specification of the business to programming rules and data conditions.

For example, it may force a product called object A to have a certain X attribute, or some action to be performed when an order for object B is placed. It determines how data can be created, stored and changed.

As you can see, the business layer needs to interact with the data source. But accessing this data directly is generally not a good idea. It makes it more difficult for developers to focus solely on implementing the logic correctly, since they have to understand how the data source is structured and how can data be retrieved from it.

This usually leads to problems like the appearance of duplicated code, poor implementation of the business logic, difficulties testing the logic and basically a higher chance of programming errors.

A lot of articles can be found out there describing repository design patterns, but not all are necessarily clear in the explanation.

The Repository Pattern

The solution to this conundrum is to add another layer between the data source and the business layer. A repository is one of the ways to do this. Generally speaking, a repository is a central location where data is stored and maintained.

The repository pattern is a design pattern in which a repository forms an abstraction layer, which is the data layer, between the data source and the business layer. This basically removes the logic to retrieve and map the data to a model from the business layer and places it in the data layer.

This way, the business layer does not have to worry about the format the data is in. It could be a database, a Sharepoint list, or a web service.

Likewise, the repository is also in charge of the ORM implementation. ORM (Object-relational mapping) is responsible for mapping object-oriented language into relational database language. With the repository pattern, this mapping is now invisible to the business layer. It could be implemented with LINQ to SQL or even ADO.NET Entity Framework, but it is now the job of the repository to worry about this.

Introducing the Repository Pattern in Magento 2

Although the repository pattern concept has been around for awhile, it wasn’t used in Magento 1 and was introduced in Magento 2. It was introduced because some deep changes were needed in Magento’s API. Let’s take a quick look at these changes.

  1. Modernizing the API with REST (Representational state transfer), while remaining backward-compatible for web stores using SOAP (Simple Object Access Protocol). Both REST and SOAP are web service communication protocols which provide interoperability between network systems.
  2. Maintaining functionality across the old SOAP API, the new REST API, and any potential future API.
  3. Refactoring the Magento ORM layer.
  4. Achieving this with a team that had gaps in terms of Magento 1 experience.

One of the major ways the Magento team found to do all of this was to implement the repository pattern. This has resulted in an improved overall performance of the platform relative to Magento 1 because all CRUD operations (Create, Read, Update & Delete) were moved to the repository, or data layer.

A lot of articles can be found out there describing repository design patterns, but not all are necessarily clear in the explanation.  A lot of articles can be found out there describing repository design patterns, but not all are necessarily clear in the explanation. The description varies from one programming language to another, so it can get confusing sometimes.  Here, we'll try to begin with the basics, explaining how applications are layered, what a repository is and introduce the repository pattern. Then we’ll talk about how it was implemented in Magento 2 and what does it mean for users of this platform.

How Does it Work?

This small example shows how the business logic and data retrieval and storage is separated with the usage of the repository pattern. Basically, loading and saving the data is done through the repository, while accessing or changing a data field is done by the business logic. The repository maps the data from whatever format it is stored in the data source into the $model object, local to the business layer.

// Load data from persistent storage
$model = $modelRepository->loadById($id);
// Read data from model
$name = $model->getName();
// Change data on model
$model->setActive(true);
// Save the changes to persistent storage
$modelRepository->save($model);

Note that this example is simplified. There are other samples that go in-depth on how to set up classes, create objects and using the repository. Our intent here is just to explain the repository pattern concept to Magento 2 users, who may find it new.

The repository pattern approach does have one drawback. There is a useful feature in web pages, especially for mobile devices, which is lazy loading. We call it lazy because elements like images are only loaded if they are within the screen area. For example, it means that when you visit a web store, only the top images are loaded, and the other ones are loaded as you scroll down on your device.

However, in Magento 2, as is illustrated in the example above, when we perform a load operation all the data is loaded, and not just the needed data. So, when you open a Magento 2 web store, it takes more time to load because all the images are being retrieved from persistent storage.

There are already some extensions that work their way around this limitation and allow for lazy loading in Magento 2. You can find some of them in the Magento Marketplace.

Conclusion

The introduction of the repository pattern improved the API standards in Magento 2. This has benefitted developers, who now have an easier job customizing and building extensions for the popular eCommerce platform.

Overall, this change has led to improved performance, functionality, security and stability in Magento 2 compared to Magento 1.