Magento 2 Repositories and Practical Software Engineering

If you’re following along with Magento 2 development, you’ve probably heard the drum beat that the Model/Resource Model/Collections are old and tired, and the Repository classes are new and wired. While the move towards repositories is is a Good Thing™, a Magento 2 developers still needs to know the old CRUD system, and that CRUD system is likely to remain with us for a long time coming.

I was reminded of this recently as I took some time to dig into some changes in the UI Component feature in Magento 2.1. Most of (all of?) the Grid listings in Magento 2 still rely on collection models.

The pattern is a UI component configuration binds something called a data provider class

<argument name="class" xsi:type="string">MagentoReviewUiDataProviderProductReviewDataProvider</argument> 

This is the class responsible for returning the data a grid will use. These data providers extend a base MagentoUiDataProviderAbstractDataProvider which assumes the presence of a Magento collection model.

namespace MagentoReviewUiDataProviderProduct;    
//...
use MagentoUiDataProviderAbstractDataProvider
//...

class ReviewDataProvider extends AbstractDataProvider   
{
    public function __construct(
        $name,
        $primaryFieldName,
        $requestFieldName,
        CollectionFactory $collectionFactory,
        RequestInterface $request,
        array $meta = [],
        array $data = []
    ) {
        parent::__construct($name, $primaryFieldName, $requestFieldName, $meta, $data);
        $this->collectionFactory = $collectionFactory;
        $this->collection = $this->collectionFactory->create();
        $this->request = $request;
    }    
}

If repositories are the one true way forward for Magento’s model layer why is this core code — core code that’s critical to the user interface of Magento’s backend — still relying on Collection models?

Not being a member of Magento’s core engineering team, I can only speculate, but it seems like the individual or team behind the UI Component features of Magento took a look at the repositories, realized they weren’t ready for prime time, and instead chose to use the collection resource models that are are already battle tested (collection classes that, as an aside, most repository classes still rely on).

From someone living in a world of pure code this probably seems like “bad” software engineering — but it’s actually the opposite. Basing your systems and code on the idealized version of the universe feels great, and gives you a big finger to point at someone else when the component you’re relying on doesn’t ship in time, but at the end of the day shipping code that works means making practical choices that will let you continuously ship working software. For all of Magento 2’s exploration of the upper atmosphere, it’s encouraging to see there’s still some practical engineering going on.