Magento – Correct way to obtain a session object

checkoutmagento2session

I'm writing a payment module for Magento 2 right now and I'm checking it against the
"Magento Extension Quality Program Coding Standard" CodeSniffer
(https://github.com/magento/marketplace-eqp).

For every of my classes that are using a (checkout) session object, the CodeSniffer responds with the following warning:

Session object MUST NOT be requested in constructor. It can only be passed as a method argument.

I'm getting the session object in the following way:

/**
 * Checkout session object
 *
 * @var \Magento\Checkout\Model\Session
 */
protected $checkoutSession;

/**
 * Constructor
 *
 * @param  \Magento\Checkout\Model\Session $checkoutSession
 * @return void
 */
public function __construct(\Magento\Checkout\Model\Session $checkoutSession)
{
    $this->checkoutSession = $checkoutSession;
}

Is there a correct way to obtain the session object?
I couldn't find anything in the Magento 2 core code.
I could only find code where it is used in exactly the same way I use it.

Best Answer

Magento Docs are saying

If a class’s constructor is particularly resource-intensive, this can lead to unnecessary performance impact when another class depends on it, if the expensive object does not end up being needed during a particular request.

Magento has a solution for this situation: proxies. Proxies extend other classes to become lazy-loaded versions of them. That is, a real instance of the class a proxy extends is created only after one of the class’s methods is actually called. A proxy implements the same interface as the original class and so can be used as a dependency anywhere the original class can. Unlike its parent, a proxy has only once dependency: the object manager.

Proxies are generated code and therefore do not need to be manually written. (See Code generation for more information.) Simply reference a class in the form \Original\Class\Name\Proxy, and the class is generated if it does not exist.

Magento 2 Proxies

So, in your case

/**
 * Checkout session object
 *
 * @var \Magento\Checkout\Model\Session\Proxy
 */
protected $checkoutSession;

/**
 * Constructor
 *
 * @param  \Magento\Checkout\Model\Session\Proxy $checkoutSession
 * @return void
 */
public function __construct(\Magento\Checkout\Model\Session\Proxy $checkoutSession)
{
    $this->checkoutSession = $checkoutSession;
}

Note \Proxy suffix for the object \Magento\Checkout\Model\Session

Related Solutions

Magento 2.1 – Use urlBuilder->getUrl() in Custom Module Controller

If your controller extend Magento\Framework\App\Action\Action you should follow rules of creation of the controller. So you should implement dependency injection of the parent class constructor (Magento\Framework\App\Action\Action):

/**
 * @param Context $context
 */
public function __construct(Context $context)
{
    parent::__construct($context);
    $this->_objectManager = $context->getObjectManager();
    $this->_eventManager = $context->getEventManager();
    $this->_url = $context->getUrl();
    $this->_actionFlag = $context->getActionFlag();
    $this->_redirect = $context->getRedirect();
    $this->_view = $context->getView();
    $this->messageManager = $context->getMessageManager();
}

Your construct method should look like this after a modifications:

/**
 * @param Context $context
 * @param UrlInterface $urlBuilder
 */
public function __construct(
    Context $context,
    UrlInterface $urlBuilder
) {
    parent::__construct($context);
    $this->urlBuilder = $urlBuilder;
}

NOTE: do not forget to remove old var/generation directory after implementing of modifications, because there are stored the generated files of controllers.

Best Way to Load a Custom Model in Magento 2

Best practice: via the service contract

The best practice is always to use the service contract whenever it's possible. You can find the list of reasons here: Magento 2: what are the benefits of using service contracts?

For details on how to implement a service contract I suggest you check this topic: How to implement service contract for a custom module in Magento 2?

If no service contract available

If there is no service contract available, you should use the model repository get method. Using this method, you benefit from the magento caching system for example for the CategoryRepository class:

public function get($categoryId, $storeId = null)
{
    $cacheKey = null !== $storeId ? $storeId : 'all';
    if (!isset($this->instances[$categoryId][$cacheKey])) {
        /** @var Category $category */
        $category = $this->categoryFactory->create();
        if (null !== $storeId) {
            $category->setStoreId($storeId);
        }
        $category->load($categoryId);
        if (!$category->getId()) {
            throw NoSuchEntityException::singleField('id', $categoryId);
        }
        $this->instances[$categoryId][$cacheKey] = $category;
    }
    return $this->instances[$categoryId][$cacheKey];
}

Deprecated `load()` method

Magento 2 is slowly moving away from the standard CRUD system by dropping the inheritance system and implementing it via composition using the new 2.1 EntityManager you can find details here: Magento 2.1: using the entity manager

Also I suggest you read this interesting topic about the deprecated CRUD methods: Deprecated save and load methods in Abstract Model

Why not using the resource model load

The main reason is that if you use the resource model load method, you will skip some important part of the loading system that are implemented in the model load method, see Magento\Framework\Model\AbstractModel :

public function load($modelId, $field = null)
{
    $this->_beforeLoad($modelId, $field);
    $this->_getResource()->load($this, $modelId, $field);
    $this->_afterLoad();
    $this->setOrigData();
    $this->_hasDataChanges = false;
    $this->updateStoredData();
    return $this;
}

Calling the resource model load method directly will have the following impact:

_beforeLoad is not called: thus the model load before events are not dispatched
_afterLoad is not called: thus the model load after events are not dispatched
the stored data are not updated which can cause various problems (for instance if you call prepareDataForUpdate from Magento\Framework\Model\ResourceModel\Db\AbstractDb )