What I did was extending zend table and storing it inside my models and abstracting calls to database within the object iself. I did it on small scale for now, so I'm not sure how will this work out for me in the future. The idea is to use composition instead of inheritance and if you still need to access table object directly you could do $model->getTable()->update(...) The bottom line is that the model should use the table, not be the table. Of course I may be completely wrong... will find out soon :)
Cheers Sam Davey wrote: > > Hi, > > That sort of makes sense, perhaps I should be adding database access as a > behaviour via composition rather than as a characteristic which is > inherited. > > There is no question that extending Zend_Db_Table has massive advantages. > Before v 1.0, I created my own CRUD code using Zend_Dd, but I've since > gone back and redeveloped and after extending Zend_Db_Table I was able to > reduce my code from 300+ lines to about 50. So lets say I create 3 classes > Product_Crud, Manufacturer_Crud and Category_Crud which handle things > relating to the (specific) related database table. > > As a quick by the by in answer to Bryce, I think this relates to your > post. I think I'm suggesting that my Product_Crud would extend > Zend_Db_Table... in fact no, it will extend Zend_Db_Table_Abstract so it > can handle the data validation as well. So this would encompass your > Defaults.php and Validation.php classes. > http://framework.zend.com/manual/en/zend.db.table.html#zend.db.table.extending > > Would this be a good approach for CRUD? (Not my original question) > > But this really just defers my question and I am no closer to a solution. > Okay, lets assume the above and my models now don't extend Zend_Db_Table. > My Models (Product, Manufacturer, Category) are now business objects and > focus on functionality not data. Do I really throw method after method at > it if I need different sets of results? > > Lets have some concrete examples: > 1. I want my CMS user to choose from a list of products. So I need > Product Id, Manufacturer Name and Product Name. I create a method which > uses Zend_Db to execute a join and get me my result set. > > 2. I want a list of products and the categories they are in. So I create a > method which uses Zend_Db to execute a join and get me my result set. > > 3. I want a list of products and their prices (which is in a seperate > table to handle difference currencies). So I create a method which uses > Zend_Db to execute a join and get me my result set. > > I could go on and on. In the strict world of MVC do I have to create a > new method for every report I need to create which needs a different > reults set? > > If so then I can see my classes getting very bloated very quickly. > > What do people think? > > Cheers, > > Sam > > > Karol Grecki wrote: >> >> Hi Sam, >> >> IMHO model classes should not extend the table. They should reflect >> business objects and focus on functionality not data. If they need >> database access you can give them reference to a table object. I try to >> avoid "database driven development", I decide what functionality I need >> and the database is just a place where I store stuff, not something that >> I build my application around. >> What if you want your manufacturer to inherit from something like user or >> client? You already said it's type: table, does it make sense? >> >> >> Cheers >> Karol >> >> >> Sam Davey wrote: >>> >>> I've created 3 models, product, manufacturer and category. Each extends >>> Zend_Db_Table but offers a custom findByFilter() method which returns a >>> result set based on data from a filter form. So far so good, it all >>> works, I get data from the particular table the model relates to. >>> >> >> > > -- View this message in context: http://www.nabble.com/Models%2C-Objects-and-RDBMS---Best-Practise-tf4052812s16154.html#a11521812 Sent from the Zend Framework mailing list archive at Nabble.com.
