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#a11521206 Sent from the Zend Framework mailing list archive at Nabble.com.
