* In the code you write for your Model class, you might create instances
* of one or more classes that each extend Zend_Db_Table_Abstract. Query
* these objects, fetch the results you need, combine them into the best
* structure that is easily utilized by your View scripts, and return the
* aggregate data. The consumer of the Model class (e.g. a View script) is
* shielded from any knowledge that the data were produced from multiple
* tables.
I understand this part. Since the View doesn't have to know anything about
the datasource - we agree with this - I must return a data structure
independent of the datasource. So in this simple example I think I have to
return my own Article objects with my own Picture objects (which do not
extend Zend_Db_Table), and return an array of Article objects and each
Article object contains a list of Picture objects (which I will build in
this method). Per consequent I will have two similar kind of objects :
* DBArticles : extending Zend_Db_Table;
* DBPictures : idem
* Article : my own class to be returned to the view. In which I'll have a
set of objects Picture.
* Picture
And as I said in my previous comment, I'll have something poddling like :
> [...]
> $art = new Article();
> $art->setName($sqlResult->name);
> $art->setPrice($sqlResult->price);
> [...]
> return $art;
> [...]
Since I may not return a class extending Zend_Db_Table to the View but
rather create my own objects.
So I will have to initialize my own objects according to the returned DB
objects (rows). (E.g. in the code above, to avoid returning a DB object to
the View I map all its values with my own object.)
(Maybe I could write a method which maps the values between a Zend_Db_Table
object with my own objects.)
For the simple example returning a set of articles containing themselve a
set of pictures, this will already imply a lot of conversion :
(sorry it's a kind of pseudocode, started php when started zf)
$articles = new Arraylist
SQL find the articles
foreach row ($$dbArt) in the returned Rowset
{
$art = new Article();
$art->setName($dbArt->name);
$art->setPrice($dbArt->price);
SQL find all related pictures
foreach row ($dbPic) in the returned Rowset
{
$picture = new Picture();
$picture->setPath($dbPic->path);
$picture->setDescription($dbPic->description);
$art->addPic($picture); // <= Now I have a better OO approach :
// each Article contains a
set of Picture
}
add $art in the $articles arraylist
}
return arraylist $aricles (which will now not return any db related code)
* Instead, a Model class like yours should be an OO representation of a
* set of Articles and associated Pictures.
I am not sure about that. As I said above I would rather have an Article
class. Picture class. And have one class containing a set of methods which
will return DB data inside my own objects (will return Article, Picture, ...
or an array of Articles, Pictures, ...).
I hope I am clear and you understand my point of view.
Bill Karwin wrote:
>
> Hi,
>
> I'm trying to make the case that the interface of Model classes need not
> be determined by the physical storage of the data storage (i.e. tables
> and databases).
>
> Instead, a Model class like yours should be an OO representation of a
> set of Articles and associated Pictures. The methods of this class
> should be about things you might want to do with this dataset,
> regardless of the fact that it is eventually stored in a database. You
> don't necessarily have to have methods that match the methods of
> Zend_Db_Table. In other words, if the data were stored in flat files
> instead of a database, how would you design this class?
>
> In the code you write for your Model class, you might create instances
> of one or more classes that each extend Zend_Db_Table_Abstract. Query
> these objects, fetch the results you need, combine them into the best
> structure that is easily utilized by your View scripts, and return the
> aggregate data. The consumer of the Model class (e.g. a View script) is
> shielded from any knowledge that the data were produced from multiple
> tables.
>
> And even if that changes in the future, they still don't need to know --
> you just rewrite the code inside your Model class. As long as your code
> manipulates data into the same resulting structure, the usage of your
> Model class doesn't need to change.
>
> Regards,
> Bill Karwin
>
>> -----Original Message-----
>> From: debussy007 [mailto:[EMAIL PROTECTED]
>> Sent: Friday, October 05, 2007 3:00 PM
>> To: [email protected]
>> Subject: [fw-general] RE: Database - relations
>>
>>
>> Hello, thank you for your reply.
>>
>> If I understood correctly, in practice, I would have my own
>> business objects.
>> E.g. in my example (simplified) I would
>> * create a class Article with all the attributes in the class
>> and a list of pictures.
>> * create a class Picture
>> * put these classes in my directory "models"
>>
>> * create a kind of "Data Access" class, which implements an
>> Interface defining all the methods concerning data access
>> from a persistent storage (here database). (these methods
>> will be sql calls and returning the business objects).
>> * create one Data Access class per table ??? or one for the
>> whole database ??
>> * put these classes in a dao directory ??? (to separate the
>> classes defining the model in dir "models" and the class
>> allowing operations on these model
>> classes)
>>
>> For each sql-select I would have something plodding like:
>>
>> [...]
>> $art = new Article();
>> $art->setName($sqlResult->name);
>> $art->setPrice($sqlResult->price);
>> [...]
>> return $art;
>> [...]
>> (Since I lost the advantage of Zend_DB_Table)
>>
>> Also, this implies, no more use of Zend_DB_Table at all.
>>
>> Am I correct ?
>>
>>
>>
>> Bill Karwin wrote:
>> >
>> > Right; using a class of type Zend_Db_Table as your Model
>> works only if
>> > your logical Model maps to a single physical Table in the database.
>> >
>> > The best solution in more complex cases is to write your own Model
>> > class to encapsulate the business logic needed to produce a
>> combined
>> > result set from multiple Table objects. You could even
>> write methods
>> > that execute direct SQL if you want to do a true JOIN query. So a
>> > Model's relationship to its Table(s) is "has-a" rather than "is-a".
>> >
>> > Encapsulating business logic in a Model class allows you to treat a
>> > Model as a single logical class, even if it is backed by multiple
>> > database tables or queries. It also allows the Model to surface a
>> > consistent interface, even if the database structure
>> changes from time
>> > to time in the future.
>> >
>> > Regards,
>> > Bill Karwin
>> >
>> >> -----Original Message-----
>> >> From: debussy007 [mailto:[EMAIL PROTECTED]
>> >> Sent: Friday, October 05, 2007 1:46 PM
>> >> To: [email protected]
>> >> Subject: Re: [fw-general] Database - relations
>> >>
>> >>
>> >> Thank you.
>> >>
>> >> What confuses me is that these methods, I can only call them on a
>> >> fetched row (Zend_Db_Table_Row_Abstract).
>> >>
>> >> But I want to send to my view all my articles with all
>> their pictures.
>> >>
>> >> If I use these methods, I have to fetch in my controller all the
>> >> articles and set them as a view variable.
>> >> Then in the view, use these methods for each row (for each
>> article,
>> >> get the related pictures by doing the queries with the methods).
>> >> Which I think is not respecting the MVC pattern (no
>> business logic in
>> >> the view).
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> redphantm wrote:
>> >> >
>> >> > Check out this thread
>> >> >
>> >> <http://www.nabble.com/Saving-Related-Model-Data-tf4539948s161
>> > 54.html#a12957145>.
>> >> > Also read
>> >> >
>> >> <http://framework.zend.com/manual/en/zend.db.table.relationshi
>> >> ps.html>
>> >> > in the manual. These should be enough to provide you with
>> >> an example
>> >> > on how to do your methods.
>> >> >
>> >> > debussy007 wrote:
>> >> >>
>> >> >> Hello.
>> >> >>
>> >> >> In my DB I have a table "articles" and a table
>> "pictures" and one
>> >> >> article can have one or more pictures.
>> >> >>
>> >> >> I want to display the list of the articles and their photos.
>> >> >> But in my controller I can retrieve the list of the
>> >> articles but how
>> >> >> do I associate the list of pictures for each article ?
>> >> >> I want to avoid having sql operations in the view to
>> retrieve for
>> >> >> each article the photos, is his possible ?
>> >> >>
>> >> >> If I think 'Object Oriented', I should send to the view
>> a list of
>> >> >> Articles containing each all the details from the
>> database of the
>> >> >> Article AND a list of Pictures.
>> >> >>
>> >> >> This is how I retrieve the articles :
>> >> >> $this->view->myArticles = $articles->fetchAll($where);
>> >> >>
>> >> >> This gives me the Articles objects. How do I associate
>> the photos ?
>> >> >>
>> >> >> Maybe there is better way also ?
>> >> >>
>> >> >> Thank you for any kind help !!
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >> http://www.nabble.com/Database---relations-tf4577387s16154.htm
>> > l#a13067071
>> >> Sent from the Zend Framework mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Database---relations-tf4577387s16154.htm
>> l#a13068099
>> Sent from the Zend Framework mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/Database---relations-tf4577387s16154.html#a13071568
Sent from the Zend Framework mailing list archive at Nabble.com.
