2009/10/7 Eric Bauman <baum...@livejournal.dk>: > > On 7/10/2009 7:25 PM, David Otton wrote: >> >> 2009/10/7 Eric Bauman<baum...@livejournal.dk>: >> >>> Any thoughts would be much appreciated! >> >> One observation. "Model" isn't a synonym for "Database Table" - models >> can be anything that encapsulates business logic. Requiring all your >> models to inherit from Model is probably a bad idea. > > Thank-you for responding. > > Out of curiosity, why is this a bad idea? Is it also bad for views & > controllers?
Well, the way MVC has traditionally been approached is that the VC bit is a thin interface skin, concerned with I/O, while the M is the bulk of the program - the bit that does the heavy lifting. (You'll often hear this called "Fat Model, Skinny Controller"). So you could have a lot of models, that do a lot of disparate stuff - not just database tables. To give you an example, imagine an application that texts people when a new book by their favourite author is coming out. It's going to have models to represent database tables, the Amazon API and an SMS API. If all your controllers assume that all your models inherit from Model, then your code is monolithic and none of it can be reused. http://c2.com/cgi/wiki?InheritanceBreaksEncapsulation Of course, I'm talking about a general-purpose framework here - if all you're ever going to do is CRUD operations on DB tables, then by all means make assumptions about your models. You end up with all your classes tightly coupled, but they're still perfectly fit for purpose. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
