John Zumbrum
John Zumbrum

Reputation: 2856

Zend Framework Data Layer Architecture

I'm following the Zend QuickStart guide, and am a bit confused by the architecture for connecting to a database. I see 4 layers:

ModelClass
ModelClass_Mapper
ModelClass_DbTable
Actual MySQL Database

I've used an architecture before where there is one file that has properties that map directly to the database, and an extended class that holds all of the custom code for hooks and database action events.

Where can I find a good explanation of why it's necessary to have three files like this, instead of just having ModelClass inherit DbTable?

Upvotes: 2

Views: 467

Answers (4)

RockyFord
RockyFord

Reputation: 8519

The ZF quickstart provides an example of The Data Mapper pattern that seems to work reasonably well with ZF 1.x. It is not required that you implement a Data Mapper to use Zend_Db. You can get quite good functionality just using the DbTable models and the methods provided by Zend_Db_Table_Abstract.

To explain a bit:

Application_Model_Guestbook: would be a simple Domain Model (the object you interact with).

Application_Model_GuestbookMapper: would be the data mapper to map the database columns to the propeties of the domain model.

Application_Model_DbTable_Guestbook: is the gateway model that provides the connection between the database and the database adapter. This is where you can specify options for your database table and relationships with other tables.

It took me a little experience with ZF and Models before I figured out how the data mapper applied to my applications. I really began to understand how these pieces fit together when I started building objects that depended on more then one database table.
'

You'll notice that a number of experienced ZF developers recommend Doctrine or some other ORM right away, for them that is probably the correct choice (and seems to be reflex for some). I just feel that I shouldn't start using an ORM until I understand at least the basics of what that ORM is doing.

[EDIT]

fetchAll() equivalent method in base mapper class, pass in instance of Zend_Db_Table_Abstract to the __constructor

public function findAll($order = NULL) {
        $select = $this->_getGateway()->select();
        if (!is_null($order)) {
            $select->order($order);
        }
        $rowset = $this->_getGateway()->fetchAll($select);
        $entities = array();
        foreach ($rowset as $row) {
            //abstract method required in each table mapper, this instantiates the domain model
            $entity = $this->createEntity($row);
            //identiy map allows lazy loading of certain members
            $this->_setMap($row->id, $entity);
            $entities[] = $entity;
        }
        //returns an array of domain models instead
        return $entities;
    }

the createEntity() method from of my table specific mappers

public function createEntity($row) {

        $data = array(
            'id'     => $row->id,
            'name'   => $row->name,
            'art'    => $row->art,
            'year'   => $row->year,                
        );

        $entity = new Music_Model_Album($data);
        //set artist id to reference map for lazy loading
        $entity->setReferenceId('artist', $row->artist_id);
        return $entity;
    }

Good Luck

Upvotes: 3

Config
Config

Reputation: 1692

A very good explanation is given here: http://martinfowler.com/eaaCatalog/dataMapper.html

A short quote:

The Data Mapper is a layer of software that separates the in-memory objects from the database. Its responsibility is to transfer data between the two and also to isolate them from each other. With Data Mapper the in-memory objects needn't know even that there's a database present; they need no SQL interface code, and certainly no knowledge of the database schema. (The database schema is always ignorant of the objects that use it.) Since it's a form of Mapper (473), Data Mapper itself is even unknown to the domain layer.

Upvotes: 2

Ismael Vacco
Ismael Vacco

Reputation: 1030

The Zend_Db_Table solution is an implementation of the » Table Data Gateway pattern. The solution also includes a class that implements the » Row Data Gateway pattern.

You can look whose patterns in Table Data Gateway and Row Data Gateway

Upvotes: 0

moteutsch
moteutsch

Reputation: 3831

Personally, though I love the Zend Framework, I find the data layer libraries to be rather poor. What I now use is Doctrine combined with Bisna to integrate the two. Perhaps you should take a look at those as well?

Upvotes: 0

Related Questions