Yeah, I generally agree with this statement. I've found that in my apps so far, I have used both models that extend Zend_Db_Table_Abstract/Zend_Db_Table_Row_Abstract and others that are standalone.
I'm not sure that it's an ill fit for "most apps". Within any given app, I'd expect a mixture (for apps done by people who are not 100% OO-centric at least)! I don't think I've ever had a case where there's a one to one mapping from controller to model. Even simple stuff like a blog with comments needs at least two. Regards, Rob... Bill Karwin wrote: > Rob, how do you feel about this somewhat different statement I gave on a > fw-db thread: > > Q: "Is there a best practice when it comes to defining models on top of > the Zend_Db_Table_Row class?" > > Regarding best practices of defining models, this is a frequently asked > question. It's hard to make a one-size-fits-all solution for this, > because application requirements vary so much. In some cases, you can > define a model class that extends Zend_Db_Table_Abstract or > Zend_Db_Table_Row_Abstract. But it's my belief that most apps have > requirements for business logic that make this an ill fit. You'll soon > find cases where you need to write a model class that extends nothing > (i.e. your model is itself a base class) and it may _use_ one or more > Table or Row objects, in addition to other resources. > > Both simple and complex cases exist, so don't feel constrained to define > models in a particular way in every case. Step back and do the analysis > necessary to find the best OOP solution. Also keep in mind that there's > no requirement for a given controller action to use only one model > object. It's okay for a controller to create instances of multiple > models. So let the OO analysis determine which code belongs in which > class. > > Regards, > Bill Karwin
