There are multiple technologies used by Magento, with its web server and Database components. Its web server is being created using PHP scripting language whereas Database part is taken care of by MySQL. Data model being utilized by MySQL is based on the EAV i.e. Entity-attribute-value model
EAV i.e. Entity-attribute-value model, whose primary feature is that it would store data objects in a tree structure. A benefit of using Tree-like structure is, data structure now can vary without changing database definition. But at the same, EAV based data model approach is expensive and should only be considered when a developer is not sure about a number of fields in a table and can vary in future. A key benefit of EAV technique is that it allows a developer to add unlimited columns to table virtually, one table would hold all the attribute data and other tables would hold the entity and value against every attribute mentioned.
Mage:getSingleton() does create only single object for a given class. If the object is already being created for the same class, it won’t create it again. As the name suggests, it utilizes a singleton design pattern. Usage of the singleton design pattern is applicable in those scenarios, where a developer wants to create a single object only one time and then later keep utilizing the very same object, modify and fetch it, but won’t create a new object. Session object could be an ideal example of this pattern, where a user can add or remove values from session across different pages in an application so that it retains the value but won’t create a new session object. Since creating a new session object means losing your last changes. This is the basic Magento Interview Questions in an interview.
Mage::getModel() does create a new object, with every time, its class is being called. Unlike, Singleton approach, it can be utilized in a scenario, where a developer requires new data from the database.
Both models are having big differences in their schema and strategy to store the data.
EAV is more of a normalized form of the database model. The primary feature of EAV based approach is that every column value is being stored in its respective data type table. Product and Model related data can be stored in their respective data type table. Product ID, product name, product price, and its creation date would be stored in their respective data type table. It means, a developer needs to join multiple tables to get the product details, which actually brings more complexity as well in EAV based approach.
Unlike EAV based approach, Flat model utilizes a single table. It is not normalized, unlike its EAV counterpart and hence uses more database space. A primary feature of the Flat model is performance since only a single query can load entire product, thus developer need not do complex join queries to get product detail
There are two types of sessions being used, customer and checkout sessions. All customer related data is locked with customer session whereas data related to order and quotes are stored in the checkout session. Session types are utilized separately since order get placed, check out session data information needs to be flushed. Thus, having two different sessions for order and customer related data makes sense. Example – customer session’s first name will be $_SESSION[‘customer’][‘firstname’].
Q6. In Magento 2, what are the different deploy modes and what are their differences?
In this mode, all the files in pub/static/ are symlinks to the original file. Exceptions are thrown and errors are displayed in the front end. This mode makes pages load very slowly, but makes it easier to debug, as it compiles and loads static files every time. Cache can still be enabled.
This default is enabled out-of-the-box. It is a state in between production and developer, as the files are generated when they are needed. I.e. CSS files are generated using several LESS files in several locations. These files will be generated only when they are needed by the front end, and will not be generated again the next time they are needed.
This mode should be enabled for all Magento 2 websites in production, as all the required files are generated and placed in the pub/static folder.
Q7. what is dependency injection and what are its advantages?
Dependency injection is a design pattern strategy that relegate the responsibility of injecting the right dependency to the calling module or framework. This is the Hollywood Principle: “Don’t call us, we’ll call you.”
The responsibility of calling the right dependency is no longer handled by the function and respects.
Its main advantages are that it makes code:
Q8. what is a factory class and how does it work?
Factory classes are generated when code generation happens. They are created automatically for models that represent database entities.
Factory classes are used to create, get, or change entity records without using the ObjectManager directly, as its direct usage is discouraged by Magento. (This is because it goes against the principles of dependency injection.)
These classes do not need to be manually defined, but they can be, in case you need to define a specific behavior.
Q 9. What Are The Features Of Magento 2?
Here are the following key features of Magento 2:
Q 10. Which Class Magento 2 Helper Extend?
Magento Framework App Helper AbstractHelper
Q 11. Which Function Refers to The Action In Any Controller File?
Its execute() function.
Q12. What Is The Difference Between Cache: clean And Cache: flush?
Typically, cache:c lean deletes all enabled cache related to magento whereas cache: flush deletes the whole cache storage, whether its magento cache or any third party cache (whether enabled or disabled)
Q13. What Is Resource Attribute For Admin Menu Item?
Resource attribute defines the ACL rule, that a user must have in order to access this Menu Item.
Q 14. How can you improve the performance of Magento?
There are a number of things that you can do to enhance and improve Magento performance.
Doing all of the following can improve Magento performance.
Disabling any modules that are not being used
Disabling the Magento log
MySQL Query Caching
Optimizing your image
Enabling Gzip Compression
Enabling Magento Caching
Combining the external CSS/JS into a single file
All of these things can speed up Magento and make it work better. This can be very helpful for both the ecommerce company, and for the customers of the company.
Q15. How many design patterns does Magento Have?
Magento has a total of 12 design patterns. These patterns include:
Q16. How many tables will be created when you make a new EAV module?
If you make a new EAV module, then six tables will be created. These tables include:
module_datetime, module, module_decimal, module_int, module_text, and module_varchar.
Q 17 What is a Plugin?
A plugin, or interceptor, is a class that modifies the behavior of public class functions by intercepting a function call and running code before, after, or around that function call. This allows you to substitute or extend the behavior of original, public methods for any class or interface.
Extensions that wish to intercept and change the behavior of a public method can create a Plugin class.
Q18.How to override controller in Magento2?
To override controller we need to create a basic module structure. In our below code we have Hello module that will override Product view controller.
Create di.xml file in Folder Letsknowit/Hello/etc
our complete path is app/code/Letsknowit/Hello/etc/di.xml
<config xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xsi:noNamespaceSchemaLocation=”urn:magento:framework:ObjectManager/etc/config.xsd”>
<preference for=”MagentoCatalogControllerProductView” type=”LetsknowitHelloControllerRewriteProductView” />
Q19. What is a UI component in Magento2
In Magento UI component is a combination of:
Q 20: How can we write custom module in Magento 2?
If we need to create our own module say – Hello World then we define it in app/code folder. It will be app/code/VendorName/moduleName.
Create the folder of Hello World module
Create etc/module.xml file
Create etc/registration.php file
Enable the module
Q21 .What is Object Manager in Magento?
The initialization of objects in Magento is done via what is called the object manager. The Object Manager itself is an instant of the Magento\Framework\ObjectManager\ObjectManager class that implements the Magento\Framework\ObjectManagerInterface class.
create($type, array $arguments = ): This creates a new object instance. The $type argument is a model, block or helper class name or interface name. It is analogous to Mage::getModel().
get($type): The get method will check to see if an instance of the object of type $type has already been instantiated and return that. Otherwise, it will instantiate a new object of type $type and return that instead. It is analogous to Mage::getSingleton(). Again, the $type argument is a model, block or helper class name or interface name.
If we want to specify that an object we’re injecting should be instantiated as a singleton, then we can specify the shared=” true” attribute in the di.xml.
<type name=”Magento\Framework\App\RouterList” shared=”true”>
Q22 Which files are necessary to install – upgrade database tables and records in it?
Normally, there are four files for this listed below
Q23. How Magento ORM works?
ORM stands for Object Relational Mapping. It’s a programming technique used to convert different types of data to Objects and vice versa.
In Magento, ORM is shown as Model (based on Zend Framework’s Zend_Db_Adapter), which further breaks down to two types of Models.
– First is the “simple” i.e. Regular Models which is nothing but flat table or our regular table structure.
– Second Model is EAV (Entity Attribute Value), which is quite complicated and expensive to query.
Q23. what di.xml file ?
The di.xml file configures which dependencies are injected by the object manager. You can also specify sensitive configuration settings using di.xml.
Areas and application entry points
Each module can have a global and area-specific di.xml file. Magento reads all the di.xml configuration files declared in the system and merges them all together by appending all nodes.
As a general rule, the area specific di.xml files should configure dependencies for the presentation layer, and your module’s global di.xml file should configure the remaining dependencies.
Magento loads the configuration in the following stages:
During bootstrapping, each application entry point loads the appropriate di.xml files for the requested area.