Ben, One thing i noticed awhile ago was that it really helped to keep my feet on the ground at this stage. You can conceptualize a model from different perspectives. Alan Shalloway in Design Patterns Explained talks about Conceptual, Specification, and Implementation perspectives.
You can get really confused trying to *implement* a model from a conceptual perspective. What i'm saying is that you might not need the gateway composed into your bean to display what you need to display to the user. You might only need the gateway feeding a display. Conceptually, a publication will have authors and categories. And you might debate whether the publications should be composed into categories or the other way around. Or both. But practically, you'll probably only need to instantiate the bean when you're editing a publication. The rest of the time, a simple publication gateway can just pull the records you need using a single query with a join. i hope that makes sense. >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Behalf Of Ben Nadel >Sent: Wednesday, December 14, 2005 7:23 PM >To: [email protected] >Subject: [CFCDev] Object relations, getting, setting, and validation Oh >My! > > >Starting to get a better handle on the whole OOP but another question. I >know this has been touched on before on different threads, but a >me-specific >example would help me wrap my head around it. > >Lets say I have a publication. It can have authors. It can be associated to >categories. > >What I am thinking is having the following items (naming is to be clear): > >PubicationEntity >PublicationDAO >PublicationGateway > >AuthorsGateway >CategoriesGateway > > >I understand the straight up bean data. What I am needing help with is the >non-bean data such as authors and categories (defined by joining, rather >than row data). > >What I am thiking is that the pub entity has methods like GetAuthors() and >GetCategories() But instead of doing anything, what the pub entity really >does is just redirect to the appropriate gateways: > ><cffunction name="GetAuthors" returntype="query"> > Return >VARIABLES.AuthorsGateway.GetByPublication(VARIABLES.Instance.ID) /> ></cffunction> > ><cffunction name="GetCategories" returntype="query"> > <cfreturn >VARIABLES.CategoriesGateway.GetByPublication(VARIABLES.Instance.ID) /> ></cffunction> > > >Maybe I am way off base here (its happened before), but what I like about >this is it really separates out the different pieces of data. > >Now this is just the GETTING side of things. I am not sure how I would do >the validation/setting side. Like, if a Pub needed at least one author... >where would that validation be? I assume it would be part of the Pub Entity >Bean, but then it would have to store author data in order to validate >count... hmmmm. > >One step at a time. > >Any help would be great. I think once I get passed this linked object step, >the rest of the object relationships will make sooooo much more sense. > >Thanks! >...................... >Ben Nadel >Web Developer >Nylon Technology >6 West 14th Street >New York, NY 10011 >212.691.1134 >212.691.3477 fax >www.nylontechnology.com > >"Vote for Pedro" > > > > >---------------------------------------------------------- >You are subscribed to cfcdev. To unsubscribe, send an email to >[email protected] with the words 'unsubscribe cfcdev' as the >subject of the email. > >CFCDev is run by CFCZone (www.cfczone.org) and supported by >CFXHosting (www.cfxhosting.com). > >An archive of the CFCDev list is available at >www.mail-archive.com/[email protected] > > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
