Modelling Tables

Zend_Db_Table is a class that represents a table. You instantiate one of these and call query functions against it. The actual code for my classes is really minimal, here’s an example:

class UserTable extends Zend_Db_Table
{
    protected $_name = 'users';
    protected $_rowClass = 'User';
}

The two properties that I’m setting here are all I use for basic tables. $_name tells Zend Framework which database table to use. $_rowClass tells it which class it should instantiate for the results from your select query. By default you’ll get Zend_Db_Table_Row objects but you can have it use any object which extends this class instead.

Getting Results

To get results from a table, you instantiate the relevant table class, and then fetch some results. You can restrict the results you get but Zend_Db_Select is a whole other kettle of fish that perhaps I’ll post about some other day. So a controller action might look something like this:

function viewAction()
{
    $users = new UserTable();
    $user_list = $users->fetchAll();
}

The $user_list variable will then hold an instance of Zend_Db_Rowset.

Working with Rowsets

The rowsets are iterators, you can loop over them and they will return objects which represent the rows in the resultset of the query. By default these are objects of type Zend_Db_Table_Row but if you set the table object’s rowClass, either in the object declaration or by calling setRowClass() before you fetch the results, then you can have any class which extends Zend_Db_Table_Row used. Its pretty common to pass the rowset straight to the view and iterate over it there – you can put any functionality you need for this object into the class you use. Let’s look at my user class for this example.

The Row Class

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

        public function getProfileUrl()
        {
            return '/users/profile/id/' . $this->id;
        }
    }

These are overly simple examples, but giving this kind of functionality to the user model allows it to be re-used any place you need it. I’ve also found it useful to have an intermediate table row class that contains functionality that will be used by data from more than one table – for example for formatting dates in a consistent manner.

Zend Framework and Models

This is a pretty simple overview but it took me a while to get to this point – the framework does have documentation but its quite case-specific and doesn’t really show how it ties together. Now I understand these classes and their relationships, my development project is going a lot more smoothly.