Hi, I like the reasoning and am trying to work with it at the moment. So how might these table and model class files best be organised? Should I put the table classes and the model classes in the same directory or should I try and separate them out? eg.
|-- controllers |-- models | |-- business | | |-- Image.php | | |-- Images.php | | |-- User.php | | `-- Users.php | |-- rdb | | |-- Images.php | | `-- Users.php | `-- xml `-- views I guess that also means more path hassles too but maybe tidier? Regards, Mark Maynereid On Tuesday 10 July 2007 17:20, Bill Karwin wrote: > I agree with the other statements that best practices include making > Model classes that are decoupled from database table representations. > > The assumption that there's a one-to-one mapping between Models and > Tables is more or less a characteristic of Ruby. We can see many > examples where this assumption does not hold true. Adding methods to a > concrete Table class to join to secondary tables, combine data with > other logic or data, etc. doesn't seem like the right solution. > Instead, a Table class should provide a general interface to a single > Table, and you should use one or more such classes in a given Model > class. > > Take for example a case where a given database table is used in multiple > controller actions, but it is used in different ways. One fetches a > paged result set, another gets a count of rows, etc. Should you make a > Model that extends Zend_Db_Table_Abstract and use it in all cases? You > may have to add many methods to do custom behavior, even if only one of > these methods is applicable to a given action. It starts to resemble > the God Object antipattern (http://en.wikipedia.org/wiki/God_object). > > Instead, make a Table class as generic as possible; all it does is > provide an interface to query the database table. Then create multiple > separate Model classes, which use the Table class in specific ways. > Then it becomes a lot easier to structure a Model that needs to access > multiple tables, or a feed, or a file on disk, etc. > > Also keep in mind that Models are not just about data. They may need to > perform other business logic, and this might not correspond to any > database table. > > Regards, > Bill Karwin
