Architecture - 2.1 Basic Concepts: MVC, Templates, and Layouts

Question 1

What is Magento architecture based

on, and how does Magento architecture affect the Magento 2 application?

Answer 1

• Magento is built on the MVC idea. Model / View / Controller.
• Model is the data. Ultimately, the model concept goes way deeper than this into data storage and retrieval.
• View is how the data is presented. This is the HTML and CSS side.
• Controller is the link between the model (data) and the view. This provides the business logic for what data to show where

Question 2

Database sharding and varnish caching

Answer 2

• (EE only) Sharding is splitting up a database into multiple “shards” (think of a broken glass).
• This allows for performance gains and scalability in different configurations. The database can be split into different segments: checkout orders and products.
• This also allows data to be backed up, data analysis without affecting the master database, and scalability.
• More information: http://devdocs.magento.com/guides/v2.0/ config-guide/multi-master/multi-master.html
• Varnish caching
• Varnish is a reverse-proxy caching engine.
• It sits in front of the web server (apache or nginx) and if a request is cached, it will return that. This results in a very low latency caching engine. Response times are often sub 200ms.

Question 3

Templates and layouts in Magento 2: Basic responsibilities and roles when executing Magento code

Answer 3

• Templates contain the HTML; layouts are XML files that contain instructions for what to show, where, and details for how to
show it.
• The layout XML files are merged together to form one set of instructions per page. This gives tremendous capabilities for customizing a website.
• Templates are PHP and HTML. They accept PHP objects and other data and render them as HTML.

Question 4

Extending Magento 2 functionality with a code change or enabling an extension—basic concepts and process steps

Answer 4

• To extend Magento, the first thing is to determine what needs to be changed. This specification is signed off by the customer and work can begin.
• It is important that modules don’t get too big. This makes them difficult to manage and maintain. Follow the Single Responsibility Principle.
• After registration.php and etc/module.xml are present, you can run bin/magento module:enable ((MODULE NAME)).
• This turns the module on, and development can continue.
• You will likely have to run bin/magento setup:upgrade and bin/magento setup:di:compile.
• Once the module is complete, you would commit it, have it peer-reviewed, and ensure that it passes QA and then deploy to production.

Question 5

Configuring site design using options found in the admin under Content > Design > Configuration

Answer 5

• This was a much improved area in Magento 1 over Magento 2. The design configuration is found in Content > Design > Configuration.
• Select the store / theme combination that you wish to work with, and click Edit.
• This pretty much replaces the System > Configuration > Design area. It is specific to the theme, and makes much more sense to place in this location.
• Adding configuration to this area is still not the easiest.

Question 6

Installing and enabling/disabling Magento 2 extensions

Answer 6

• It is very important to first review the code (line-by-line) of each extension installed. I’m always amazed at how many security vulnerabilities and sending requests back to the module developer’s servers (phoning home) that I find.
• Installing the module is very easy (instructions for a one-off Magento instance not connected to builds or anything):
• SSH into the server
• Copy the new module files
• bin/magento module:enable ((MODULE NAME)) — omitting this will enable all modules
• bin/magento setup:upgrade
• bin/magento setup:di:compile
• bin/magento setup:static-content:deploy
• bin/magento cache:clean