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

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

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

4. 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

5. Application Models Design 1.DOMAIN AND SERVICE LAYERS Theoretical Background

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

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

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

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

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

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

12. 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

13. 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

14. Application Models Design 2.MODELS DESIGN IN MAGENTO Backwards Compatibility

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

16. 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

17. Super Models

18. 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

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

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

21. 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

22. 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

23. Application Models Design 3.COLLECTIONS DESIGN IN MAGENTO

24. 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

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

26. 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_*

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

28. The Triangle Collections Resource Layer Domain Entities 3x ~200

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

30. What is ORM Magento Doctrine ORM 2.x

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

32. 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)

33. 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

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

35. Application Models Design 5.POSSIBLE SOLUTION FOR MAGENTO Magento 2

36. 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

37. 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)

38. Memento Pattern for Entities Data

39. 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)

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

41. Service Layer and Multiple RDBMSs Zend_Db_Adapter_Abstract Zend_Db_Adapter_Pdo_Mysql Varien_Db_Adapter_Pdo_Mysql

42. 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

43. Service Layer and Multiple RDBMSs

44. 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

45. Making it Work Together

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