Thanks, Peter.
> Take a look at the Page Controller pattern and the DataMapper. The
Since I'm not handling requests or presenting any data at this point, I don't see the use of the Page Controller. My
descriptions may have been confusion though. A Store is an online catalog I from which want to archive the data, a
Page is one of multiple pages in a Store and a Product is one of multiple products on a Page.
However, it looks like the classes I currently have follow the Data Mapper pattern. From Fowler's brief description,
the Data Mapper is useful when an object requires parts that aren't in the database. But when all the parts *are* in
the database, why have another level of abstraction? My Store and Product objects have no extra parts, but the Page
object does. Should I use a Data Mapper for Store and Product for consistency sake, or should I abstract only Pages?
> Table Row Gateway is intended only to give an object interface to the
> row of data.
I'll accept that. But when would you extend it? Allen in ZFiA (p117-118) advocates adding "parts" to the Row Data
Gateway that manipulate the row's data and using __get() to handle method requests.
>
> - pw
>
> On Fri, Jul 16, 2010 at 9:06 PM, Brad Waite <freebsd@wcubed.net
> <mailto: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
>
>
没有评论:
发表评论