He asked me for some advice and I provided some information on the sorts of things he need to learn about and some ideas on where to find communities that will help.

I had recently read Cal Evans' PHP and Community post, which contains this gem:

Until all 4.6 million PHP developers are active in the community, there is always a seat at the table. If you are a PHP developer - junior level, architect level or just a weekend warrior - I urge you to get involved.

Start a blog and write about what you have learned. Trust me, if you put up something that isn’t accurate, someone will come along and correct you. That’s a win for everyone.

As a result, I also advised him to start a blog so that he can document what he now knows to the benefit of us all and also allow potential employers the opportunity to understand his skills much better than a mere CV can show.

He's taken this advice and http://jibbles.co.uk/ has been born. It turns out that Chris is a very good writer - much better than I was when I started (and probably better than I am now too)! If you are interested in watching a new coder develop into a better coder, then it may be worth keeping an eye on his blog. You could also comment periodically when he needs a pointer to something that he's probably never heard of before :)

Martin Fowler has summed up pretty much how I feel about it:

The nub is that whatever the presenter may think, people were offended - both in the talk and those who saw the slides later. It doesn't matter whether or not you think the slides were pornographic. The question is does the presenter, and the wider community, care that women feel disturbed, uncomfortable, marginalized and a little scared.

I find it discouraging that we need to ask this question in this day and age, but I'm assured by women I know in the IT industry, that they deal with prejudice because of their sex day in day out in their working lives.

Martin goes on to say:

I have a different vision - one that sticks it to the suits so hard it will make their eyes water. How about a community where women are valued for their ability to program and not by the thickness of their skin? How about a community that edgily pushes new boundaries without reinforcing long running evils? Perhaps even a community where women reach equal numbers? Such a community would hand the suits the defeat in the long battle women have been fighting for centuries. I'd love to be part of that.

Hear hear! That's what I want to be part of too.

I recommend that you read all of Martin Fowler's article as it provides a good grounding in a lot of the issues involved, especially if you read the other articles he links to.

It turns out that they've put up a sample of the book on Scribed! Check out the book, then order it, remembering to use the coupon code scribd25...

The "is a" relationship

When working with models within Zend Framework, the simplest solution is to extend Zend_Db_Table_Abstract and Zend_Db_Table_Row_Abstract along these lines:

class Users extends Zend_Db_Table_Abstract
{
    protected $_name = 'users';
    protected $_rowClass = 'User';
    
    public function fetchAllInLastNameOrder()
    {
        return $this->fetchAll(null, array('last_name', 'first_name'));
    }
    
    public function fetchUserById($id)
    {
        $id = (int)$id;
        return $this->_fetchRow('id = '. $id);
    }
}

class User extends Zend_Db_Table_Row_Abstract
{
    public function name()
    {
        return $this->first_name . ' ' . $this->last_name;
    }
}

This works fairly well for models where there is a one to one mapping to the underlying database table. It starts to falls down if a given model needs to know about two or more database tables to do its work.

The knack is to avoid using the functions defined in Zend_Db_Table_Abstract within your models or views as this will lead towards fat controllers that are too aware of the underlying database. This gets quite hard as it's much easier to start putting model logic into the controllers with this system, especially when it comes to choosing if you need to insert or update a record. A sure sign that you have this problem is that your controllers create SQL statements or Zend_Db_Table_Select objects.

To try and avoid these problems, there have been discussions on the ZF mailing lists for a little while now about using a "has a" relationship from the model object to the Zend_Db_Table object. Bill Karwin has long been a proponent of this idea and recently there's been much discussion about it. The question is: how do you implement it in practice without ending up writing lots of code for the sake of "cleanliness"?

I've started a new ZF project recently where I've started playing with these ideas and this is my first attempt at it, so I thought I'd share where I had got to in my thinking.

The "has a" relationship

When implementing this relationship we are trying to hide the fact that we are using Zend_Db_Table from the consumers of the models. The basic idea is that we have a gateway class that holds a protected $_table variable that is an instance of a Zend_Db_Table object. When fetching data, the gateway object will return either a single object or an array of objects of a type which I've not-very-imaginatively named "StandardObject".

This is a picture of the various objects and how they relate to each other:

To get this working, I first mapped out how I want the objects to work via a unit test and then built the classes behind it. I wouldn't call it TDD though as I didn't write tests for all the internals as I went along. This is the basic API that I want my consumers to use:

$userGateway = new UserGateway();

// insert a row
$data = array();
$data['first_name'] = 'John';
$data['last_name'] = 'Smith';
$row = $userGateway->setFromArray($data);

// update a row
$data = array();
$data['id'] = 1;
$data['first_name'] = 'Rob';
$data['last_name'] = 'Allen';
$row = $userGateway->setFromArray($data);

// fetch a single user
$row = $userGateway->fetchUserById(1);

// fetch all users
$rows = $userGateway->fetchAllInLastNameOrder();

// delete a user
$result = $userGateway->deleteById(1);

The general idea is that I can write specific functionality into the UserGateway class as I need it. Note also that the row objects returned from the gateway class methods behave a little like ValueObjects only. As they are not attached to the database though, they cannot "save" themselves. (I couldn't find the "correct" design pattern name, which probably means, that my design is wrong!) This means that all interaction with the database is via the gateway class which makes this design similar in some ways to the Table Module design pattern.

The implementation is fairly involved, so get ready for lots of code!

Firstly we need the Gateway class:

class UserGateway extends App_Model_Db_StandardGateway 
{
    protected $_tableName = 'UsersTable';
    protected $_rowClass = 'UserObject';
    
    public function fetchUserById($id)
    {
        $id = (int)$id;
        return $this->_fetchRow('id = '. $id);
    }
    
    public function fetchAllInLastNameOrder()
    {
        $orderBy=array('last_name', 'first_name');
        return $this->fetchAll($orderBy);        
    }
}

The UserGateway contains the specific methods for this model and has a couple of protected variables that are used to set up the system. We also need a table class, UsersTable that inherits from App_Db_Table_Standard which inherits from Zend_Db_Table_Abstract.

class UsersTable extends App_Db_Table_Standard
{
    protected $_name = 'users';
}

Obviously we are going to have many gateway models, so it makes sense that common functionality will be in a parent class, which I've called App_Model_Db_StandardGateway. This is the big class and we'll look at it in chunks:

class App_Model_Db_StandardGateway
{
    /**
     * @var App_Db_Table_Abstract
     */
    protected $_table = null;
    protected $_tableName = null;
    protected $_rowClass = 'App_Model_StandardObject';

    public function __construct()
    {
        if (empty($this->_tableName)) {
            throw new Exception('You must specificy _tableName');
        }
        $this->_table = new $this->_tableName();
    }

Every gateway has a $_table property which is instantiated in the constructor. The name of the table class to instantiate is stored in the $_tableName property which is set in the child class. Finally, we have a $_rowClass property which will be used to hold each row object when the data is retrieved from the database. Note that it defaults to App_Model_StandardObject, but I assume that the child class will override with a specific row class as the UserGateway class does when it specifies that it wants to use the UserObject row class.

The first thing in our API is the ability to create or update database rows. I've decided on a function called setFromArray() as a foundational function to allow this. The base implementation is performs these steps:

1. Get hold of an instance of the row class
2. Call the row's setFromArray() method
3. Call the row's save() method

This is implemented as:

// (part of App_Model_Db_StandardGateway)

    public function setFromArray($data)
    {
        $row = $this->_fetchRowOrCreate($data);
        $row->setFromArray($data);
        $row->save();

        return new $this->_rowClass($row->toArray());
    }

The tricky bit is getting the instance of the row class (an instance of Zend_Db_Table_Row) as we need to either create a new one or retrieve it from the database. Creating a new one is easy: $row = $table->createRow(). However, retrieving a row based on the $data array is more complicated. The simplest way I could think of was to retrieve the primary key info from the table and then call find() with the correct fields from $data array. To do this, I had to extend Zend_Db_Table_Abstract to implement a getPrimary() method like this:

class App_Db_Table_Standard extends Zend_Db_Table_Abstract
{
    protected $_rowClass = 'App_Db_Table_Row_Standard';
   
    public function getPrimary()
    {
        return $this->_primary;
    }

}

Note that we also define a custom row class, App_Db_Table_Row_Standard which will allow us to perform operations on insert and delete.

Back to the App_Model_Db_StandardGateway class, we can now create _fetchRowOrCreate():

// (part of App_Model_Db_StandardGateway)

    /**
     * Either retrieve a row from the DB or create a new one
     *
     * @param array $data
     * @return App_Db_Table_Row_Standard
     */
    protected function _fetchRowOrCreate($data) 
    {
        $pk = $this->_table->getPrimary();
        if (!is_array($pk)) {
            $pk = (array) $pk;
        }
        
        $pkData = array();
        foreach ($pk as $fieldName) {
            if (array_key_exists($fieldName, $data)) {
                $pkData[] = $data[$fieldName];
            } elseif (!empty($pkData)) {
                throw new Exception("Could not find Primary Key part '$fieldName'");
            }
        }
        
        if (empty($pkData)) {
            $row = $this->_table->createRow();
        } else {
            $rowset = call_user_func_array(array($this->_table , 'find'), $pkData);
            if ($rowset) {
                $row = $rowset->current();
            } else {
                $row = $this->_table->createRow();
            }
        }
        return $row;
    }

I'm nearly sure this can be improved, but it works for both a simple autoincrement primary key like id and also for compound primary keys of multiple columns which is nice. The method makes an assumption that if you have a compound key, then the $data array will have an entry for all fields that make up the primary key. If not, an exception is thrown. We also assume that if none of the fields that make up the primary key are present in $data, then you want to create a new record.

That covers creating and updating database records from our gateway class. Deletion is a simple proxy directly to the table class:

// (part of App_Model_Db_StandardGateway)

    public function deleteById($id)
    {
        $count = $this->_table->delete('id = '. (int)$id);
        return (bool) $count;
    }

so let's look at fetching data. We need two methods in the App_Model_Db_StandardGateway class: _fetchRow() and fetchAll(). These are trivial to implement as we proxy directly to the table class and then all we need to do it turn each row returned into an instance of our StandardObject class:

// (part of App_Model_Db_StandardGateway)

    protected function _fetchRow($where, $order = null)
    {
        $row = $this->_table->fetchRow($where, $order);
        if ($row) {
            $row = new $this->_rowClass($row->toArray());
        }
        return $row;
    }

    public function fetchAll($orderBy=null)
    {
        $rows = null;
        if(is_null($orderBy)) {
            throw new Exception('You must choose the order of the results');
        }
        $rowset = $this->_table->fetchAll(null, $orderBy);
        if($rowset) {
            $rows = array();
            foreach($rowset as $row) {
                $rows[] = new $this->_rowClass($row->toArray());
            }
        }
        return $rows;
    }

The StandardObject class' full name is App_Model_Db_StandardObject and is trivial:

class App_Model_Db_StandardObject
{
    function __construct($data = array()) {
        foreach($data as $fieldName=>$value) {
            $this->$fieldName = $value;
        }
    }
}

Obviously, the intention is that the model specific version, UserObject in this case, is able to do provide model specific functionality. For testing, I simply added a name() method:

class UserObject extends App_Model_Db_StandardObject  
{
    public function name()
    {
        return $this->first_name . ' ' . $this->last_name;
    }
}

Clearly, I could provide additional methods as required and could overload the constructor if I wanted to do a more complicated mapping from the database row array to the value object representation.

Summary

This entry has turned out much longer than I expected! This is clearly my first attempt at putting the database inside the model and hiding it from the rest of the application. Having implemented this far, I'm not sure if using Zend_Db_Table is actually useful, so my next step will be to remove it and use SQL and a Zend_Db_Adapter instead. If it turns out well, I may blog about it :)

I'm also hoping to spark more debate on the actual implementation of how to do stuff like this. I know Keith Pope is working along similar lines for the example app in his upcoming book, so if you are interested in this approach, have a look at his tactics too as they may make more sense. Matthew Weier O'Phinney has also been doing something similar in his pastebin app which is worth looking at too, though he's halfway through refactoring.

Obviously, comments and suggested improvements are welcome!

Obviously, never one to miss an opportunity to win free swag, I've entered with an article on recursion.

Now it's your turn. Write a article on a best practice when coding PHP, but don't make it too good as I want to win!

We’ve decided that IE8 will, by default, interpret web content in the most standards compliant way it can. This decision is a change from what we’ve posted previously.

From Microsoft's Interoperability Principles and IE8.

This is good news all round. It's nice to see that Microsoft have listened to the comments surrounding their original intention to make IE8 render like IE7 by default. Well done!

You know the problem: you're in a conversation and someone mentions something about a new technology that you haven't heard of. Your eyes glaze and you have that Blank Stare...

Sixty Second Tech is the solution. Once a week, it will deliver a short podcast (presumably about 60 seconds long!) that explains one technological concept per episode that you (or your less-techy friends!) need to know.

Head on over there and subscribe to the RSS Feed now - or wait for it to turn up on iTunes shortly.