> it is possible to extend the row class and add business > logic such as validation to it.
Just because you can doesn't mean to say that you should. I would separate the validation from the model altogether to gain more benefits. Doubtful if inheritance is a viable solution in this case anyways as you are therefore directly coupled to the database layer. Favour composition over inheritance, as inheritance to one degree or another breaks encapsulation. Also, remember if you inherit from those abstractions, you are stuck with them... Do you know what's around the corner? Paulo Nei wrote: > > The model layer is about business AND data. Zend_Db* have focus on data, > but you can add business logic to it, mostly if you have a simple model. > > For example, it is possible to extend the row class and add business > logic such as validation to it. Or the row can act as a value object (vo > pattern), and be passed through the controller and view layers. > > I prefer, when possible, to use only the framework classes, to maintain > code simple. It is not a problem to encapsulate the model layer into > database and row classes or to write other classes for vo's or for > business logic only... The model neither only the vo classes, nor only > the data classes. The important thing is to build, with all these > classes, a layer. > > Regards, > Paulo > > Greg Frith escreveu: >> Thanks Bill, >> >> I've just about come to this conclusion myself having read through the >> great thread suggested by Karol. >> >> Essentially now I know there is no one best way of doing things. >> >> Many thanks, Greg Frith. >> >> >> On 20 Jul 2007, at 16:52, Bill Karwin wrote: >> >>> Right; I don't believe it's appropriate to assume that a "model" can >>> simply extend a table or row object. It's better to write your own >>> model class, extending nothing, that may use a table or row object, and >>> may also use other sources of data, such as a SOAP service. >>> >>> Regards, >>> Bill Karwin >>> >>>> -----Original Message----- >>>> From: Greg Frith [mailto:[EMAIL PROTECTED] >>>> Sent: Friday, July 20, 2007 4:35 AM >>>> To: [email protected] <mailto:[email protected]>; >>>> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >>>> Subject: [fw-general] Data models >>>> >>>> Hi list, >>>> >>>> A request for thoughts/advice if I may. I have an entity >>>> which I wish to model, let's say for now it's a car. I want >>>> to be able to use a 'car' object (or list of car objects) in >>>> my view. For example $car->colour, $car->engineSize. >>>> >>>> Now, some of the information my site presents about the car >>>> comes from a SOAP web service running on another server, and >>>> some additional information comes from a local MySQL >>>> database. I understand all the Zend_Db_* classes and how I >>>> might use them to model my database car info. But I'm not >>>> too sure how to create an object that represents a car >>>> combining information from both the Web Service and the database. >>>> >>>> If for example I was to extend Zend_Db_Table_Row_Abstract to >>>> represent the car, could I add additional public fields to >>>> hold the data obtained through the Web Service without >>>> creating problems when I use ->save and such methods? >>>> >>>> Or would I perhaps be better creating a car class that >>>> doesn't extend Zend_Db_Table_Row_Abstract. Then either use >>>> the basic Zend_Db class's or extend them slightly to do the >>>> DB work for a car. Calling the various find and save methods >>>> from the car class? >>>> >>>> Thoughts? >>>> >>>> Many thanks, Greg Frith. >>>> >>>> >> >> -- >> Greg Frith >> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> : +44 7970 925 257 >> >> MSN: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >> Jabber: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >> Skype: gregfrith >> >> >> > > -- View this message in context: http://www.nabble.com/Data-models-tf4116540s16154.html#a11753818 Sent from the Zend Framework mailing list archive at Nabble.com.
