Hey guys - 

Just some thoughts going on in my head in concerns of composite
objects and the SQL utilised in getting all their details.

Reading Matt Woordards blog post:

He talks about composition, and to copy paste:
We're using composition in our beans, so why not use composition of
sorts (this isn't strictly composition, but bear with me ...) in our
DAO as well? When we instantiate the Person DAO, why not just
instantiate an Address DAO inside the Person DAO so we can call things
that way?

Now, in my mind - there are two options for getting the PersonBO
information and the AddressBO information.

1) Seperate SQL queries for both BO's - The Address DAO gets the
results for a Address, and the PersonDAO gets the results for the
Person BO - there are 2 query hits on the db.
Pros: It's clean, and consise and really reusable
Cons: For complex objects, that's alot of database hits - is that a good idea?

2) Joins between tables - a Gateway object (maybe?) gets a joined
result by getting the relevent data form both the Person Table and the
Address Table, and the DAO's intelligently create the BO's that they
need from that single query's results
Pros: It's alot more efficient than the above
Cons: It doesn't exactly promote code reuses
          It also can get tircky as Joins can cause duplicate data to
display, and you have to avoid creating the same BO twice or more.

What is your thoughts on this, guys? It's always been something that
make me think.


W: www.compoundtheory.com
ICQ: 3094740
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' 
in the message of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).

An archive of the CFCDev list is available at 

Reply via email to