Ben,
If you're just display data on a detail page, all you probably need is a
gateway. A bean is useful when you're editing data, but if all your doing is
displaying data, a gateway works just fine.
So i'm saying that you can use just a single gateway method, say
publicationGateway.findPublication(). And within that method, you use the
necessary joins to fetch the author and category stuff.
When you're editing the publication, you probably don't need to compose the
author and category stuff into the publication bean. Again, if all you're
doing is displaying a dropdown list of categories for a user to choose from,
a gateway method works fine. Your publication might have a property
"category" or "categoryID", but unless you have a specific need for the user
to edit categories within publications, you probably don't need a bean
composed within another bean, or even to compose a gateway within
Publication.
In other words, if you have a form for editing categories, you're probably
doing that separately. Imagine a link to a section of your app - Edit
Categories. Click on the link, and a list of categories appears (via
CategoryGateway). Click on a category, and a form loads (via CategoryBean).
In those moments, there is no need for a Publication bean, even tho'
Publications have Categories and Categories have Publications.
So what i'm saying is that when implementing your model, only use
composition when you really need it.
Of course, you CAN instantiate a Category, instantiate an array of
Publication objects within Category, instantiate an array of Author objects
within Publication, and call category.getPublication().getAuthor() when you
are editing a particular author, but unless you have a very practical reason
for doing so (sometimes that happens!), it's clearer and simplier just to
instantiate a single Author bean when editing an author, even if from a
conceptual level a Publication always has one or more Authors.
I'm trying to say something with the above examples that may not be exactly
what you were planning to do, of course. Just demonstrating how the
conceptual perspective can be very different from what you actually
implement, and suggesting that you can / should keep the implementation as
simple and transparent as possible.
Nando.getSomeSleep('buona serata')
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>Behalf Of Ben Nadel
>Sent: Wednesday, December 14, 2005 8:20 PM
>To: [email protected]
>Subject: RE: [CFCDev] Object relations, getting, setting, and validation
>Oh My!
>
>
>Nando,
>
>I am not sure I follow exactly. Are you saying that Publications containing
>authors is a "conceptual" idea that does not need to be implemented by the
>actual bean? Thereby saying since authors belong to publications just go
>directly to authors gateway?
>
>I like the idea of things not being coupled (the previous response).
>
>So lets say I had a detail page which is where I would need a pub entity
>bean. Of course on the detail page I would also need a list of authors (no
>cateogories, lets keep it simple).
>
>Then I would have the pub bean ex:
>
>PubBean.GetTitle()
>PubBean.GetDatePublished()
>
>And then for other stuff, I would go directly to the gateways:
>
>Authors = AuthorsGateway.GetByPublication( PubBean.GetID() )
>
>// Loop over authors
>
>
>Am I following??
>
>Thanks for the help.
>
>......................
>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"
>
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
>Of Nando
>Sent: Wednesday, December 14, 2005 2:05 PM
>To: [email protected]
>Subject: RE: [CFCDev] Object relations, getting, setting, and validation Oh
>My!
>
>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.
>
>
>
>----------------------------------------------------------
>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]
