Ibiza, June 4 th – 7 th 2011

1. Ibiza, June 4th – 7th 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 • Domain and Service Layers • Models Design in Magento • Collections Design in Magento • Entities and Service Layer in Doctrine ORM • Possible Solution for Magento

5. Theoretical Background Domain and Service Layers

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

7. Entity (Domain Model) • Represents a “real-world” entity • Defines data fields and a way to identifyan 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 Vehicle Wheel Car Car Truck Driver’s Seat Frame

11. Data Sharing Between Models

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

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

14. Models Design in Magento Backwards Compatibility

15. What are Models in Magento?

16. What are Models in Magento?

17. Super Models

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

19. Mage_Core_Model_Abstract

20. Cons Varien_Object

21. Mage_Core_Model_Resource_Db_Abstract

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. Collections Design in Magento

24. The Real Purpose of Collections Collection “Natural” Purpose 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 • To enforce data of certain type • Iterating capability • The “Lazy-Load” pattern triggered by iteration

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_Db_Adapter_* Varien_Data_Collection_Db Mage_Core_Model_Resource_Abstract Mage_Core_Model_Resource_Db_Collection_Abstract Mage_Core_Model_Resource_Db_Abstract Mage_Core_Model_Resource Mage_Cms_Model_Resource_Page_Collection Mage_Cms_Model_Resource_Page

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

28. The Triangle 3x ~200

29. Entities and Service Layerin Doctrine ORM

30. What is ORM

31. How Doctrine ORM Works Controller, View… Other Domainand Service Models Doctrine ORM XML, YAML, PHPDoc Entity Manager DB

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

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

35. Magento 2 Possible Solutionfor Magento

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 hintingin 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_*_Pdo_Mssql Zend_Db_Adapter_Pdo_Mysql Zend_*_Oracle Varien_*_Pdo_Mssql Varien_Db_Adapter_Pdo_Mysql Varien_*_Oracle

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 delegatedto separate utility class ~200 1

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!