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

Click to edit Master title style

Ibiza, June 4th – 7th 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 LAYERSTheoretical Background

Decomposing Model Layer by Role

• Domain model – an entity or business rule implementation

• Service model – application logic: instantiation, composition, collectionsand 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

Driver’s Seat Frame

Data Sharing Between Models

Entities

Customer

Quote

Product

Application

Entity Manager

Configuration

Framework

Database access

Caching

Horizontal Exchange

• One namespace between “neighbors”

• Allow dependencieson 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 requiredand valid datain 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 MAGENTOBackwards 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 termsof 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

• ConsData 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

Methods Purpose

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 structureon 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 LAYERIN DOCTRINE ORM

What is ORM

Magento

Doctrine ORM 2.x

Doctrine ORM

How Doctrine ORM Works

XML, YAML, PHPDoc

Entity Manager DB

Other Domainand Service Models

Entities

Order

Customer

Product 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 Can’t 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 serveas identity key

Application Models Design

5. POSSIBLE SOLUTIONFOR 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 hintingin 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_*_OracleZend_*_Pdo_Mssql

Varien_*_OracleVarien_*_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

~200 1

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!