Repositories give service requestors the ability to perform create, read, update, and delete (CRUD) operations on entities or a list of entities.
A repository is an example of a service contract, and its implementation is part of the domain layer.
Repository state
A repository should be stateless after instantiation.
This means that every method call should not rely on previous calls nor should it affect later method calls.
Any field contained in the repository class must also be stateless.
If your repository needs to provide functionality that requires state, such as for caching, use the registry pattern.
A good example that uses this pattern is the CustomerRepository class.
Search Criteria
A Search Criteria is an implementation of the SearchCriteriaInterface class that allows you to build custom requests with different conditions.
Repositories use this class to retrieve entities based on a matching criteria.
Filter
The Filter class is the smallest part of a Search Criteria.
It allows you to add a custom field, value, and condition type to the criteria.
Example of how to define a Filter:
This filter will find all urls with the suffix of “magento.com”.
Filter Group
The FilterGroup class acts like a collection of Filters that apply one or more criteria to a search.
The boolean OR statement joins Filters inside a single Filter Group.
The boolean AND statement joins Filter Groups inside a Search Criteria.
For example:
The code above creates a Search Criteria with the Filters put together in the following way: (url like %magento.com OR store_id eq 1) AND (url_type eq 1)
Sorting
To apply sorting to the Search Criteria, use the SortOrder class.
Field and direction make up the two parameters that define a Sort Order object.
The field is the name of the field to sort.
The direction is the method of sorting whose value can be ASC or DESC.
The example below defines a Sort Order object that will sort the customer email in ascending order:
Pagination
The setPageSize function paginates the Search Criteria by limiting the amount of entities it retrieves:
The setCurrentPage function sets the current page:
Search Result
The getList(SearchCriteria $searchCriteria) method defined in your repository should return a Search Result object.
This object is an instance of a class that implements the interface SearchResultInterface.
Search Result objects hold the Search Criteria object and the retrieved entities along with information about the total count of found entities regardless of any limitations set in the criteria.
Search Criteria Unify Processing
A Collection Processor is an implementation of the CollectionProcessorInterface interface that unifies the application of custom filters, sorting, and paginating.
It contains a one method process that applies a Search Criteria object to an abstract database collection.
You can use virtual typing in your di.xml file to specify the processors used in the Collection Processor.
Filter Processor
The FilterProcessor class applies Filter Groups and their filters to a collection.
Below is the code that applies filters to a collection.
The method applies custom filters for some fields, otherwise it applies $collection->addFieldToFilter($fields, $conditions).
Show Code for addFilterGroupToCollection
You can configure this class to use a specific custom field mapping and custom filter in the di.xml file.
The example below uses dependency injection to create a virtual type from a Filter Processor that applies the module-specific ProductCategoryFilter on a particular field mapping.
Show code for ProductCategoryFilter
Argument
Description
customFilters
An array of filters implementing the CustomFilterInterface. These filters allow you to apply custom logic to a particular abstract database collection.
fieldMapping
Maps field names defined in the search Criteria to the names in an abstract database collection
Sorting Processor
The SortingProcessor class applies the sorting order of a search criteria to an abstract database collection.
Below is an example of how you can configure a Sorting Processor virtual type in the di.xml file to use a custom field mapping and default sorting orders.
Argument
Description
fieldMapping
Maps field names defined in the search Criteria to the names in an abstract database collection
defaultOrders
The ordering applied when there are none defined in a search criteria.
Pagination Processor
The PaginationProcessor class applies the current page and page size of the search criteria to an abstract database collection.
Join Processor
The JoinProcessor class allows you to join fields from other tables into an abstract database collection.
Below is an example of creating a Join Processor virtual type in the di.xml file named Magento\Tax\Model\Api\SearchCriteria\CollectionProcessor\TaxRuleJoinProcessor:
The Join Processor aggregates Custom Joins objects implementing the interface CustomJoinInterface.
The di.xml configuration file excerpt below shows how you can create a virtual type for the Collection Processor by passing in a custom Filter Processor and a custom Sorting Processor.