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. > >
