Databases
StackOverflow2013
Postsdbo
POZend Framework ORM-style table data gateway vs. extending Zend_Db_Table_Abstract
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POZend Framework ORM-style table data gateway vs. extending Zend_Db_Table_Abstract
    primarykey
    data
    text
    <p>In the <a href="http://framework.zend.com/docs/quickstart/create-a-model-and-database-table" rel="noreferrer">Zend Framework Quickstart</a>, there has been a change from models that extend <code>Zend_Db_Table_Abstract</code> to the Table Data Gateway pattern.</p> <p>Personally, I have not had much experience with this pattern and I keep hearing this should most likely be used instead of the old way.</p> <p><strong>A short example from the quickstart:</strong></p> <p><em>Old way:</em></p> <pre><code>class Default_Model_Guestbook extends Zend_Db_Table_Abstract { protected $_name = 'tablename'; // do stuff } </code></pre> <p><em>New way:</em></p> <pre><code>// The actual model class Default_Model_Guestbook { protected $_comment; protected $_created; protected $_poster; // list continues with all columns } // Dbtable for this model class Default_Model_DbTable_Guestbook extends Zend_Db_Table_Abstract { /** Table name */ protected $_name = 'guestbook'; } // Mapper class Default_Model_GuestbookMapper { public function save($model); public function find($id, $model); public function fetchAll(); } </code></pre> <p>From my lacking experience with this style of programming, I find it hard to grasp the actual benefits from this latter way; I understand that this method seperates the database from the actual logic as much as possible, which should in theory make a transition to another database platform easier. However, I really don't see this happening on any project I am working.</p> <p>There is almost no doubt that I am overlooking something, so I'd love to hear your advice.</p> <p><strong>The question:</strong></p> <ul> <li><p><strong><em>Could someone please explain to me why (or if) the latter is better practice?</em></strong></p></li> <li><p><strong><em>Should I switch from the old way to the new way or are there still proper reasons for sticking with models that represent database tables?</em></strong></p></li> </ul> <p>Thanks in advance.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USAron Rotteveel
    plurals
    1. This table or related slice is empty.
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POZend Framework ORM-style table data gateway vs. extending Zend_Db_Table_Abstract
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POZend Framework ORM-style table data gateway vs. extending Zend_Db_Table_Abstract
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POZend Framework ORM-style table data gateway vs. extending Zend_Db_Table_Abstract
      1. USShane O'Grady
      1. VTFavorite
    1. CONot really an answer, so it is her. After several years I found out that abstraction is a form of art, art not always have reasons. Today I abstract the minimum I need and do stuff so I will have to code as less as possible, which in your case, if add this extra level of abstraction, won't happen.
      singulars
      1. POZend Framework ORM-style table data gateway vs. extending Zend_Db_Table_Abstract
      1. USItay Moav -Malimovka
    2. COJust to clarify, Zend_Db_Table *is* an implementation of the TDG/RDG pattern. What's going on is that they're moving to a Data Mapper patter.
      singulars
      1. POZend Framework ORM-style table data gateway vs. extending Zend_Db_Table_Abstract
      1. USjason
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload