Struggling with Zend\Db

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Struggling with Zend\Db

Brad Waite-2
Hello, Great Zend Masters!

I need to separate some bits of a ZF1 project into a new project and figured the shiny new ZF2 was the way to go.
Zend_Db in ZF1 was very straightforward to me. However, I'm having a hard time figuring out how to apply what's being
done in ZF1 in the new ZF2 Zend\Db.

On the surface, it appears that Zend\Db\TableGateway corresponds to Zend_Db_Table, Zend\Db\ResultSet to
Zend_Db_TableRowset, and Zend\Db\RowGateway to Zend_Db_Table_Row. If so, should I use the ZF2 classes the same way I did
their counterparts in ZF1, or has the whole paradigm shifted?

In ZF1 I have a good number of tables defined like this:

    class Application_Model_DbTable_Foo extends Zend_Db_Table_Abstract
    {
        protected $_name = 'Foo';
        protected $_rowClass = 'Application_Model_DbTableRow_Foo';
        protected $_dependentTables = array('Bar', 'Baz');
        protected $_referenceMap = array([mapping here]);
    }

My row classes look like this:

    /**
     * @property int    ID
     * @property string Name
     */
    class Application_Model_DbTableRow_Foo extends Zend_Db_Table_Row_Abstract
    {
    }

The row class isn't necessary, but simply makes it easy to work with the object properties in my IDE, Zend Studio (aka
Eclipse PDT+).

My normal usage would be to instantiate Application_Model_DbTable_Foo whenever I needed to use the table in my various
Model classes. In ZF2, it appears that by using the ServiceManager, we no longer have to instantiate the table object
every time, but simply refer to it via the SM. That part makes sense.

But in the ZF2 User's Guide, the example code appears to have Album\Model\Album taking the place of the
Zend_Db_Table_Row in ZF1. If that's correct, where does Zend\Db\RowGateway fit in?

Also in the User's Guide, the Album\Model\AlbumTable seems to be a very thin Mapper. Wouldn't a concrete TableGateway
have worked just as well in this simple app? If so, would we still use the AlbumTableGateway factory in
Module->getServiceConfig()?

And wouldn't the default ArrayObject prototype work just as well as Album\Model\Album? What's the advantage of that class?

I'm probably making this harder than it needs to be, but it seems that while the Guide does a fairly good job of explain
WHAT is going on, it just doesn't explain the WHY.

Help me Obi-Wan-ZendObi. You're my only help.

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Struggling with Zend\Db

ralphschindler
> On the surface, it appears that Zend\Db\TableGateway corresponds to Zend_Db_Table, Zend\Db\ResultSet to
> Zend_Db_TableRowset, and Zend\Db\RowGateway to Zend_Db_Table_Row. If so, should I use the ZF2 classes the same way I did
> their counterparts in ZF1, or has the whole paradigm shifted?

This is more or less correct.  Now, they are not completely coupled,
they all can be used independent of one another.  One of the stronger
use cases for this independence is that in many cases, you don't
necessarily want a RowGateway object as a result from a TableGateway object.

> But in the ZF2 User's Guide, the example code appears to have Album\Model\Album taking the place of the
> Zend_Db_Table_Row in ZF1. If that's correct, where does Zend\Db\RowGateway fit in?

In that particular example, the "Table" objects are implementing the
Table Module pattern:

http://martinfowler.com/eaaCatalog/tableModule.html

and are composing TableGateway objects to do their work.  The
distinction here is a that the Table Module API deviates from that of
purely TableGateway (very database-ish) and moves closer to the "models"
API.

> Also in the User's Guide, the Album\Model\AlbumTable seems to be a very thin Mapper. Wouldn't a concrete TableGateway
> have worked just as well in this simple app? If so, would we still use the AlbumTableGateway factory in
> Module->getServiceConfig()?

There's no right or wrong answer here.  Every modeling pattern comes
with pro's and con's.  A concrete TableGateway would work as well,
instead of passing it off as a "Mapper".

> And wouldn't the default ArrayObject prototype work just as well as Album\Model\Album? What's the advantage of that class?
>
> I'm probably making this harder than it needs to be, but it seems that while the Guide does a fairly good job of explain
> WHAT is going on, it just doesn't explain the WHY.
>
> Help me Obi-Wan-ZendObi. You're my only help.

ArrayObject would work, but you dont get the same kind of data type
validation you would get by using a concrete-type "Entity", like Album.
  For example, in the AlbumTable->save() method, you'll note that it
only accepts an Album.  If all the various table modules used
ArrayObject, then you'd have to do additional checking to ensure the
right table is getting the right kind of ArrayObject.

You might also want to have a look at Rob Allens approach, which this
tutorial was lightly based off of:

https://github.com/akrabat/zf2-tutorial/

Hope that helps getting you started.
-ralph


--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]