Or this? |-- controllers |-- data | |-- rdb | | |-- Images.php | | `-- Users.php | `-- xml |-- models | |-- Image.php | |-- Images.php | |-- User.php | `-- Users.php `-- views
Mark Maynereid wrote: > > 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 > > > -- View this message in context: http://www.nabble.com/Models%2C-Objects-and-RDBMS---Best-Practise-tf4052812s16154.html#a11531460 Sent from the Zend Framework mailing list archive at Nabble.com.
