2010年7月16日星期五

Re: [fw-db] Extending Zend_Db_Table_Row_Abstract

You can get a basic explanation of the patterns here -> http://martinfowler.com/eaaCatalog/

Take a look at the Page Controller pattern and the DataMapper.  The Table Row Gateway is intended only to give an object interface to the row of data.

- pw

On Fri, Jul 16, 2010 at 9:06 PM, Brad Waite <freebsd@wcubed.net> wrote:
Hello all,

I'm trying to read, parse & save data from several online stores.  I'd like some suggestions on the the "Right Way" to
do this according to the Zend Framework (or proper design pattern) way of thinking.

For simplicity's sake, each store has multiple pages with multiple products on each page.

My first thought was, "that's easy - make Store, Page and Product classes with corresponding tables."  So I created a
class property and a column in the db for each piece of information I wanted to save from the store, along with the
requisite __construct(), load(), save() and update() methods.

After reading up a bit more on Zend_Db_Table_Row, I decided that it was far simpler to have the framework do the heavy
lifting and added a $tableRow property to each object.  load() looked something like this:

   public function load($id){
       $where = $this->table->select()->where('id = ?', $id);
       if ($this->tableRow = $this->table->fetchRow($where)) {
           $this->id            = $id;
           $this->pageNum       = $this->tableRow->pageNum;
           $this->name          = $this->tableRow->name;
           return true;
       } else {
           return false;
       }
   }

save() was the inverse, setting $this->tableRow's properties to the object properties & calling $this->tableRow->save().

After making that work, I noticed that most of my objects' properties were just being saved to their respective columns
in the db.  With the exception of a few methods to parse the HTML from the store, the only other methods were getters
and setters.

This seems like yet more duplication of effort.  Why not extend Zend_Db_Table_Row_Abstract and add other properties and
methods as necessary?  The Page class would have a fair amount of HTML fetching & parsing code, and would create new
Product objects to save.

Would this then bastardize the Row Data Gateway pattern?  Is this the "Wrong Thing" to do?  If not, should the
page-fetching and parsing routines go somewhere other than in the extended class?  How should I create new Product
objects from within the Page class (or shouldn't I)?

In other words, when do I extend Table_Row and how much should be added to those classes?

Thanks for any insights,

-BMW


没有评论: