Decomposition of Magento Controllers

Controllers are the most important thing in MVC pattern. Controller helps to receive requests, process, and render pages. To create a front-end controller and to process the request, we need to extend our controller class from Magento\Framework\App\Action\Action. This class context gives some added features to handle the request type, and to validate authorized users and so on. But in this process Magento needs to include so many classes which ultimately increase execution time.

To optimize this architecture community members came up with a great solution, i.e. decompositions of controllers.

What is the Decomposition of Magento?

Decomposition of Magento Controllers

As a developer, we no longer need to extend Magento\Framework\App\Action\Action class, instead, we need to implement from \Magento\Framework\App\ActionInterface. If we know the purpose of our custom controller(whether it is use for GET, POST, etc operation) then there are separate interfaces that we can.

\Magento\Framework\App\Action\HttpDeleteActionInterface
\Magento\Framework\App\Action\HttpGetActionInterface
\Magento\Framework\App\Action\HttpPostActionInterface
\Magento\Framework\App\Action\HttpPutActionInterface

For example :

<?php 
use Magento\Framework\App\Action\HttpGetActionInterface;
use Magento\Framework\View\Result\PageFactory;
class MyController implements HttpGetActionInterface
{
    /** @var PageFactory */
    protected $resultPageFactory;
    public function __construct(PageFactory $resultPageFactory)
    {
        $this->resultPageFactory = $resultPageFactory;
    }

    public function execute()
    {
        return $this->resultPageFactory->create();
    }
}

You can see that we have used \Magento\Framework\App\Action\HttpGetActionInterface. It is a method-specific Interface extending ActionInterface.

Performance

In older version of Magento 2(till 2.3), Magento were injecting the \Magento\Framework\App\Action\Context into Actions with a set of following classes:

\Magento\Framework\App\RequestInterface
\Magento\Framework\App\ResponseInterface
\Magento\Framework\ObjectManagerInterface
\Magento\Framework\Event\ManagerInterface
\Magento\Framework\UrlInterface
\Magento\Framework\App\Response\RedirectInterface
\Magento\Framework\App\ActionFlag
\Magento\Framework\App\ViewInterface
\Magento\Framework\Message\ManagerInterface
\Magento\Framework\Controller\Result\RedirectFactory
\Magento\Framework\Controller\ResultFactory

And these classes are no longer injected. It will significantly improve the performance and implementing a method specific interface is a much cleaner approach.

Caution

Keep in mind that some Modules have their own AbstractAction. For example, \Magento\Customer\Controller\AccountInterface additionally handles Customer Authentication.
Controller “Supertypes” are deprecated (\Magento\Backend\App\AbstractAction, \Magento\Framework\App\Action\Action, \Magento\Framework\App\Action\AbstractAction, Magento\Framework\App\Action\Action\AbstractAccount) and you should not use them anymore.
It is recommended to avoid code migration till 2.5.0 since 3-rd party observers may be subscribed to your controllers. Methods like getRequest, getResponse, getActionFlag are eliminated with the inheritance and it will lead to errors when accessing them through controller object from event.
It is recommended to use a new approach for new code only starting 2.4.0 release.
Existing Magento controllers will not be migrated until 2.5.0 to keep backward compatibility.
Please let me know your thoughts about this blog through the comment section below, or write me an email on my email id i.e. admin@asolutions.co.in. Till next time happy coding 🙂