18911840
Description
Flashcards by Aleksey Golota, updated more than 1 year ago
|
Created by Aleksey Golota
over 4 years ago
|
|
| Question | Answer |
| What is advantages of layered application design? | Stringent separation of business logic from presentation logic simplifies the customization process. Clear organization of code predictably points extension developers to code location |
| What is Magento Domain layer? | The domain layer holds the business logic layer of a Magento module. Best practice: Use service contracts to communicate with the domain layer by passing data types through strongly typed objects. Each domain-layer model contains a reference to a resource model, which it uses to retrieve data from the database with MySql calls. This resource model contains logic for connecting to the underlying database, typically MySQL. A model requires a resource model only if the model data must persist. |
| What is magento Daomain layer functions? | 1. Defining the generic Magento data objects, or models, that contain business logic. 2. (Optionally) Including the implementation of service contracts, although not their definition |
| Which files needs to bootstrap a module? | registration.php, etc/module.xml composer.json |
| Which required files to initiate a module ? | registration.php, etc/module.xml |
| How much areas in M2? | adminhtml, frontend, base, webapi_rest, webapi_soap and cron. Not all areas are always available. For instance, the cron area is only used when running cron jobs. |
| Accessing the domain layer | 1. Service contracts are the recommended way for one module to access another module’s domain-level code. This loosely coupled solution is the optimal way for most modules to access another module. 2. A module can directly call into another module. This tightly coupled solution is not recommended for most situations, but is sometimes unavoidable. 3. Domain layer code in one module can also plug itself into another module by event hooks, plugins, di.xml files (with an SPI contract) |
| registration.php | is included by the Composer autoloader (app/etc/NonComposerComponentRegistration.php). adds the component to the static list of components in module registry \Magento\Framework\Component\ComponentRegistrar. |
| etc/module.xml | specifies the setup version and loading sequence for the module. |
| module limitations | Magento 2 modules are to be completely contained within the module’s directory. All customizations and extensions are made within that folder. |
| Which type of components exists in M2? | Module Library Theme Language |
| When model requires resource model? | Only if the model data mut persist |
| What responsibility of resource models? | Executing all CRUD (create, read, update, delete) requests. The resource model contains the SQL code for completing these requests Performing additional business logic. For example, a resource model could perform data validation, start processes before or after data is saved, or perform other database operations. A simple resource model defines and interacts with a single table. |
| Which pattern use Magento for persistence layer | Active Record. In this system, the model object contains a resource model that maps an object to one or more database rows |
| What is contain presentation layer | The presentation layer contains both view elements (layouts, blocks, templates) and controllers |
| How Presentation code calls other layers | Presentation code typically calls service contracts, particularly for a storefront. However, presentation code is occasionally dependent on a specific implementation that requires the presentation code to directly call the domain layer. |
| What is a Service layer? | The service layer provides a bridge between the presentation layer and the domain layer and resource-specific data. This is implemented using service contracts, which are defined using PHP interfaces. |
| Service contract clients are? | 1. Controllers (initiated by actions of users of the storefront) 2. Web services (SOAP and REST API calls) 3. Other Magento modules through service contracts |
| Who accesses the service layer? | All calls from web service interfaces, or users working with your storefront (that is, controller-initiated requests), are typically routed through the service layer. External applications can make requests for business logic with simple SOAP and REST calls. |
| What is a Magento module? | A module is a logical group – that is, a directory containing blocks, controllers, helpers, models – that are related to a specific business feature. |
| Module locations | live in the vendor in a directory with the following PSR-0 compliant format: vendor/<vendor>/<type>-<module-name> where <type> can be one of the following values: module - for modules (module-customer-import-export) theme - for frontend and admin themes (theme-frontend-luma or theme-adminhtml-backend) language - for language packs (language-de_de) app/code/<vendor>/<type>-<module-name> |
| What is area | An area is a logical component that organizes code for optimized request processing. |
| Magento area types | Magento Admin (adminhtml): entry point for this area is index.php or pub/index.php. The Admin panel area includes the code needed for store management. The /app/design/adminhtml directory contains all the code for components you’ll see while working in the Admin panel. Storefront (frontend): entry point for this area is index.php or pub/index.php. The storefront (or frontend) contains template and layout files that define the appearance of your storefront. Basic (base): used as a fallback for files absent in adminhtml and frontend areas. Cron (crontab): In cron.php, the \Magento\Framework\App\Cron class always loads the ‘crontab’ area. Web API REST (webapi_rest): entry point for this area is index.php or pub/index.php. The REST area has a front controller that understands how to do URL lookups for REST-based URLs. Web API SOAP (webapi_soap): entry point for this area is index.php or pub/index.php. |
| Module/area interaction guidelines | Modules should not depend on other modules’ areas. Disabling an area does not result in disabling the modules related to it. Areas are registered in the Dependency Injection framework di.xml file. |
| registration.php load flow | pub/index.php -> app/bootstrap.php -> app/autoload.php -> vendor/autoload.php -> vendor/module[]/registration.php |
| What side effects can come from modules interaction? | error when module is missing or disabled error when injecting missing class (?) null or error when using object manager for missing class ReflectionException - Class MissingClass does not exist objectManager->create() = new $type() or new $type(...args) --> PHP Warning: Uncaught Error: Class 'MissingClass' not found |
Want to create your own Flashcards for free with GoConqr? Learn more.