Play-Doh: Modelling Your Objects

Play-Doh: Modelling your Objects Matthew Weier O'Phinney Project Lead Zend Framework CodeWorks 2009 Webinar Series 24 July 2009

Goals

Learn to recognize why old habits may be bad
Learn several design patterns that can help you write testable, maintainable code
Learn some techniques for altering existing behavior without rewriting existing code

What we've learned and what we do

Oooh! Let's create the schema!

Write code that uses the DB

Plain Old Mysql (POM)
ActiveRecord
Table/Row Data Gateway

And then …

we start lamenting about performance
we end up refactoring for every new feature (e.g. caching, logging)
we need to go to a Service Oriented Architecture, and effectively refactor twice

STOP THE MADNESS!

Step One

Models are just classes. Create classes.

Models have metadata and behavior; create properties and methods .

class Person { // Metadata protected $_email ; protected $_password ; protected $_username ; // Cheat: use overloading to provide // setters/getters public function __get ( $name ) { } public function __set ( $name , $value ) { } // Behaviors public function authenticate () { } public function logout () { } public function ban () { } }

Step Two

Now start thinking about data persistence .

Identify what data you need to persist
Identify how you'll persist the data
Write code for persisting data (Data Access Layer)

CREATE TABLE person ( username VARCHAR PRIMARY KEY , password VARCHAR , email VARCHAR , ); class PersonTable extends Zend_Db_Table_Abstract { protected $_name = 'person' ; protected $_primary = 'username' ; }

Step Three

Map your model to your data.

Common approaches:

Transaction Script (can even use POM)
Table Module (often with ActiveRecord or Table Data Gateway)
Data Mapper / ORM

class PersonMapper { public function save ( Person $person ) { $data = array ( 'username' => $person -> username , 'password' => $person -> password , 'email' => $person -> email , ); $this -> getTable ()-> save ( $data ); } public function fetch ( $username = null ); public function getTable (); public function setTable ( $table ); }

Some notes:

Data !== Relational Database. Data could come from a document database, filesystem, cache, or web service.
Choose an ORM that allows you to generate your schema from your entities; allows you to easily model first, and persistence comes for free.

Step Four

Move business and application logic to a Service Layer .

The Service Layer provides application logic on top of your models

Service layer in perspective Data Access Objects and Data store(s) Data Mappers Domain Models Service Layer

Benefits to a Service Layer:

Allows easy consumption of the application via your MVC layer
Allows easy re-use of your application via services
Write CLI scripts that consume the Service Layer

What kind of application logic?

Validation and filtering
Authentication and Authorization
Transactions and interactions between model entities

class PersonService { public function create ( array $data ) { $person = new Person (); if (! $data = $this -> getValidator () -> isValid ( $data ) ) { throw new InvalidArgumentException (); } $person -> username = $data [ 'username' ]; $person -> password = $data [ 'password' ]; $person -> email = $data [ 'email' ]; $this -> getMapper ()-> save ( $person ); return $person ; } }

Decorating for Fun and Profit

Decorators allow you to add or alter functionality of an existing class.

Typical decorator:

Implements same interface(s) of class being decorated
Uses overloading to proxy to decorated class
Override specific behavior you wish to modify or enhance
Add new behavior that uses existing behavior in the decorated class

Refactor to add caching? No! Decorate!

class CachingPersonMapper { protected $_mapper ; public function __construct ( PersonMapper $mapper ) { $this -> _mapper = $mapper ; } public function fetch ( $username ) { $cache = $this -> getCache (); if (! $person = $cache -> load ( $username )) { $person = $this -> _mapper -> fetch ( $username ); $cache -> save ( $person , $username ); } return $person ; } }

Refactor to provide alternate return formats? (e.g., JSON vs XML vs ...) No! Decorate!

class JsonPerson { protected $_person ; public function __construct ( Person $person ) { $this -> _person = $person ; } public function __toString () { $data = array ( 'username' => $this -> _person -> username , 'email' => $this -> _person -> email , ); return json_encode ( $data ); } }

Nicely formed objects