Magento 2.4 became a perfect opportunity to proceed with backwards-incompatible changes that were waiting for years. When I was speaking at Magento Conferences about replacing inheritance with composition, I was not aware that I was going to be a part of this history. One such change was this Pull Request and its followup introduced by Vinai Kopp. Althought this change was very expected, these PRs were not merged.
At the begining of 2020 Vinai encouraged me to continue the work on Controllers decomposition using his contribution. With his continuous support and tremendous work of Lena Orobei - together we finally delivered one of the biggest architectural changes towards decomposition of Controllers.
Solution
As a Module developer, to implement a new Controller Action you only have to implement the \Magento\Framework\App\ActionInterface.
The authentication mechanisms for Customers are also migrated!
Benefits
No need to extend
Module developers don't have to extend from any class to create a fully functional action controller.
Example controller GET Action
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 may have noticed that we use \Magento\Framework\App\Action\HttpGetActionInterface. It is a method-specific Interface extending ActionInterface. If you want to explicitly define what methods are going to be handled by the Controller, the most common interfaces are:
\Magento\Framework\App\Action\HttpDeleteActionInterface\Magento\Framework\App\Action\HttpGetActionInterface\Magento\Framework\App\Action\HttpPostActionInterface\Magento\Framework\App\Action\HttpPutActionInterface
Please be aware that the HEAD method is handled the same way that GET is.
Performance
Keeping in mind that previously \Magento\Framework\App\Action\Context was injected into Actions with a set of classes:
/**
* @param \Magento\Framework\App\RequestInterface $request
* @param \Magento\Framework\App\ResponseInterface $response
* @param \Magento\Framework\ObjectManagerInterface $objectManager
* @param \Magento\Framework\Event\ManagerInterface $eventManager
* @param \Magento\Framework\UrlInterface $url
* @param \Magento\Framework\App\Response\RedirectInterface $redirect
* @param \Magento\Framework\App\ActionFlag $actionFlag
* @param \Magento\Framework\App\ViewInterface $view
* @param \Magento\Framework\Message\ManagerInterface $messageManager
* @param \Magento\Framework\Controller\Result\RedirectFactory $resultRedirectFactory
* @param \Magento\Framework\Controller\ResultFactory $resultFactory
*/
There's no doubt that the new way of creating Controllers is much cleaner. The performance overhead caused by instantiating classes that are not used by the Controller is significally reduced.
Differences
-
Simple controllers like
customer/account/logoutSuccessexperience a5%decrease in CPU time on generation.
-
Complex controllers like
customer/section/loadexperience a> 30%decrease in CPU time on generation.
-
Common ones like
catalog/category/viewexperience a10%decrease in CPU time on generation.
Performance measurements were performed using BlackFire.io, in an isolated Docker environment with cURL requests, not being affected by Browser/Network overhead. Thanks to Christophe Dujarric for BlackFire's support.
Testing
Controllers are easier to test (due to their reduced amount of dependencies).
Inheritance of AbstractAction forces you to use at least the same dependencies that the parent class has. Unit Test for Category View has more than 70 lines of mocking dependencies, mocking Context methods to return mocked dependencies.
With the Composition approach you can inject dependencies directly to your class and inject only the ones you need (for example, only the ones you are going to use with your Unit Tests).
Caution
- Keep in mind that some Modules have their own
AbstractAction. For example\Magento\Customer\Controller\AccountInterfaceadditionally 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,getActionFlagare eliminated with the inheritance and it will lead to errors when accessing them through controller object from event. - It is recommended to use 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.
6 Comments