Click to edit Master title style Ibiza, June 4 th – 7 th 2011

Application Models Design Lessons Learned in Magento Models by Anton Makarenko, PHP-Developer at Magento 2

Research Goals: Better maintainable model layer, less code coupling Better solution for multiple RDBMSs support

Application Models Design 1.Domain and Service Layers 2.Models Design in Magento 3.Collections Design in Magento 4.Entities and Service Layer in Doctrine ORM 5.Possible Solution for Magento

Application Models Design 1.DOMAIN AND SERVICE LAYERS Theoretical Background

Decomposing Model Layer by Role Domain model – an entity or business rule implementation Service model – application logic: instantiation, composition, collections and data delivery

Entity (Domain Model) Represents a real-world entity Defines data fields and a way to identify an entity Protects data integrity Implements domain behavior

Service Model Layer Implements arbitrary application logic Arbitrary hierarchy of models for: –Data mapping –Composition of models, domains –Utility purposes

Criteria for Creating Hierarchy of Models Complexity of task Necessity for different use cases Requirements for application flexibility

Model Hierarchy Detalization Toy Car Vehicle Car Truck Wheel Drivers Seat Frame

Data Sharing Between Models Entities CustomerQuoteProduct Application Entity Manager Configuration Framework Database access Caching

Horizontal Exchange One namespace between neighbors Allow dependencies on the same level Vertical Exchange Different namespaces = mapping between models of different hierarchy levels Strive to loose dependencies Data Sharing Between Models

Entity Model Enforce all required and valid data in constructor and setters Allow to inject data only through strict interface Service Model Stateless or with predictable state Laconic public interface Data Encapsulation in Models

Application Models Design 2.MODELS DESIGN IN MAGENTO Backwards Compatibility

What are Models in Magento? Models Business logic Entities Resource Models Entity persistence Data manipulation, indexing Collections Reading sets of data Reports

What are Models in Magento? Mage::getModel() Standalone domain models Entity domain models (Mage_Core_Model_Abstract) Mage::getResourceModel() Resource models (Mage_Core_Model_Resource_Abstract) – service layer Collections (Varien_Data_Collection_Db) – also service layer Mage::helper() Helpers (Mage_Core_Helper_Abstract) – a bit of service layer as well

Super Models

Reuse Through Inheritance Constrains designing classes hierarchy No natural is-a relation Fails attempt to reuse code by bloating interface Reuse Through Composition Real is-a relations, polymorphism Less coupling, more freedom in designing classes More scalable and more expensive in terms of number of objects in memory Super Models in Magento Backwards Compatibility

Mage_Core_Model_Abstract Service Interface save() load() delete() getResource() getCollection() afterLoad() afterCommitCallback() isObjectNew() Entity (Domain) Interface N/A

Varien_Object Cons Data Object __call() getData() setData() unsetData() hasData() Irrelevant Features Entity: Get/Set ID ID field name Service: Get/Set origData hasDataChanges()

Mage_Core_Model_Resource_Db_Abstract MethodsPurpose save(), load(), delete()Entity CRUD getIdFieldName(), hasDataChanged()Relation with abstract model afterLoad()Hook for collections getTable(), getMainTable(), getReadConnection() Provide direct DB access to resource collections _prepareDataForTable(), _checkUnique()Dynamic analysis of table structure on entity save operation

Entity and Resource Models Summary Dynamic entity structure: –Domain structural inconsistency –DB DDL overhead Scattered service logic –Contaminated entity models –Code encapsulation challenge –Exposure of DB layer Backwards Compatibility

Application Models Design 3.COLLECTIONS DESIGN IN MAGENTO

Collection Natural Purpose To enforce data of certain type Iterating capability The Lazy-Load pattern triggered by iteration Collection in Magento Enforce type – Yes Iterate & Lazy-load – Yes Data set formalization: –fields, filters, limitation, sorting Part of service layer: –Deals with database –Instantiates objects The Real Purpose of Collections

Components that Depend on Collections Domain models Service layer Controllers and view (templates) Special case – (admin) grids

Collections Hierarchy Varien_Data_Collection Varien_Data_Collection_Db Mage_Core_Model_Resource _Db_Collection_Abstract Mage_Cms_Model_Resource _Page_Collection Mage_Core_Model_Resource _Abstract Mage_Core_Model_Resource _Db_Abstract Mage_Cms_Model_Resource _Page Mage_Core_Model_Resource Varien_Db_Adapter_*

Collections as Resources Duplication of resource layer logic Necessity to break encapsulation Necessity to implement collection class for each entity Backwards Compatibility

The Triangle Collections Resource Layer Domain Entities 3x ~200

Application Models Design 4.ENTITIES AND SERVICE LAYER IN DOCTRINE ORM

What is ORM Magento Doctrine ORM 2.x

Doctrine ORM How Doctrine ORM Works XML, YAML, PHPDoc Entity Manager DB Other Domain and Service Models Entities OrderCustomerProduct Controller, View…

Can Doctrine ORM Be Adopted in Magento? A ready solution for domain and service layers Entities – a best practice implementation Entity manager and data persistence Collections Database abstraction layer (DBAL)

Doctrine ORM Cant Be Adopted in Magento Migration efforts to DBAL Potential performance issues: –There are up to 30 classes loaded to instantiate an entity –Objects initialization through unserialize() – possible performance bottleneck

Future Compatibility with Doctrine ORM Entity fields to be declared as class attributes One or more entity fields to serve as identity key

Application Models Design 5.POSSIBLE SOLUTION FOR MAGENTO Magento 2

Implementing Entities Move out service layer logic from domain models: –No persistence handling –No cascade handling of other entities Enforce domain model consistency using strict constructor, type hinting in setters and declared fields

OrigData Use Cases getOrigData($key) –track changes before save (service layer) getOrigData() –log object changes (Enterprise_Logging) hasDataChanges() –rare specific cases in different places (service, controllers)

Memento Pattern for Entities Data

Implementing Service Layer Entity managers: generic for primitive entities, custom for complex entities Data (database) access inside entity manager = disband resource models Implement data set handling in entity managers (ex-collections territory)

New Entity Manager Responsibilities Deal with DB access layer directly CRUD operations Get collection data from DB

Service Layer and Multiple RDBMSs Zend_Db_Adapter_Abstract Zend_Db_Adapter_Pdo_Mysql Varien_Db_Adapter_Pdo_Mysql

Service Layer and Multiple RDBMSs Zend_Db_Adapter_Abstract Zend_Db_Adapter_Pdo_Mysql Varien_Db_Adapter_Pdo_Mysql Zend_*_Oracle Zend_*_Pdo_Mssql Varien_*_Oracle Varien_*_Pdo_Mssql

Service Layer and Multiple RDBMSs

Service Layer and Application Resources Slightly reduced collections responsibility: No more DB layer access No more objects instantiation Data set formalization delegated to separate utility class ~2001

Making it Work Together

Summary, Q & A Better maneuver space for domain models DB abstraction layer improved for better multiple RDBMSs support Lightweight service layer Thank you!