I think one of the problems with this approach is that you now cannot use
your Pub entity as a bean. Sure it still has getters/setters but now it has
more complex methods which in fact call other service/gateway objects. This
prevents you from throwing around the bean (entity). It doesn't prevent you
per se but it tightly couples the Pub entity to your AuthorsGateway.
My approach (I could be wrong) is to place all aggregate data access methods
(e.g. methods that return queries) in Gateway objects. Depending on your
approach, these methods *can* take a Pub entity as input and this to drive
the actual query (e.g. Pub.setTitle("Foobar"), and then the method
GetAuthors(Pub) would then build the SQL query by examining all the
properties of the argument Pub entity so ultimately the query would look
like:
SELECT * FROM Publications WHERE title = "Foobar"
You could/would also do your JOINs here.
Maybe I am way off-base but I like to drive my queries using Bean
properties.
/Cody
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Ben Nadel
Sent: Wednesday, December 14, 2005 10:23 AM
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]