An approach to implement model classes in zend
Download as PPT, PDF0 likes1,071 views
The document discusses different patterns for implementing model classes in Zend Framework: 1. Directly inheriting from Zend_Db_Table classes is simple but leads to tight coupling and hard to test code. 2. The Active Record pattern is also simple but shares the same cons as directly inheriting. 3. The Data Mapper pattern is highly recommended as it separates business logic from data access logic, allows for complex business rules, parallel implementations, complete decoupling and easy testing without a database connection. Sample code is provided for this pattern.
An approach to implement model classes in zend
- 1. Quynh Le, PHP Developer swiss IT bridge gmbh www.swissITbridge.ch An approach to implement Model classes in Zend Framework
- 2. Agenda Overview Patterns Reference
- 3. Overview - Zend Framework (ZF): MVC - Strategy: Fat Models, Skinny Controllers - ZF does not provide guideline for Model implementation. But, it provides Zend_Db component, including: Zend_Db_Adapter Zend_Db_Table Zend_Db_Table_Row Zend_Db_Select
- 4. Patterns Directly inheritance from Zend_Db_Table Active Record Data Mapper
- 5. Patterns (cont.) Directly inheritance from Zend_Db_Table class Employee extends Zend_Db_Table_Abstract { protected $_name = 'employees'; protected $_primary = 'id'; //Business logic methods public function calculateAge() { } } Pros : - Simple and easy to implement Cons : - Hard to test without database connection - Tight-coupling with Zend_Db_Table - Hard to change data source (Oracle, XML, SOAP, ...)
- 6. Patterns (cont.) 2. Active Record class Employee extends ActiveRecord { //Storage logic methods public function insert(){} //Business logic methods public function calculateAge() { } } Pros : - Simple and easy to implement Cons : - Hard to test without database connection - Tight-coupling with Zend_Db_Table - Hard to change data source (Oracle, XML, SOAP, ...)
- 7. Patterns (cont.) 3. Data Mapper (Highly recommended) Separate Business logic & storage logic
- 8. Patterns (cont.) 3. Data Mapper (cont.) Patterns: - Lazy loading: Huge data fields, or relation objects - Identity map: Avoid to load the same object twice - Dependency injection: Initialize mapper objects
- 9. Patterns (cont.) 3. Data Mapper (cont.) Service Layer: - Place on the top of Domain Model and Data Mapper - Extend business logic - Forwards calls to Domain Model or Data Mapper
- 10. Patterns (cont.) 3. Data Mapper (cont.) Service Layer:
- 11. Patterns (cont.) 3. Data Mapper (cont.) Pros: - Can handle very complex business logic - Parallel implementation - Complete decoupling - Model is not aware of storage - Clean storage interface (implement different storages) - Can test without Database connection Cons: - Quite much code to write
- 12. Patterns (cont.) 3. Data Mapper (cont.) Sample code:
- 13. Reference Book: Patterns of Enterprise Application Architecture (Martin Fowler, 2002)
- 14. Thank you
Editor's Notes
- #3: what would you like to discuss
- #4: what would you like to discuss
- #5: what would you like to discuss
- #6: what would you like to discuss
- #7: what would you like to discuss
- #8: what would you like to discuss
- #9: what would you like to discuss
- #10: what would you like to discuss
- #11: what would you like to discuss
- #12: what would you like to discuss
- #13: what would you like to discuss
- #14: what would you like to discuss
- #15: what would you like to discuss