Your TO is a snapshot of the state contained within your business
object (BO), which is what you're calling a bean.  So if you have a BO
that you need to display in your view, persist to the database, or
whatever, you'd ask the BO for a TO containing it's state, and then
the view or persistance layer would use the getters on the TO to do
whatever it needs to do.

The reason you don't want to pass the full BO into your view or
persistance layer is that it exposes the potential for business
methods to be called on your BO outside the business logic layer.  By
using a TO, you avoid that, because there aren't any business methods
on the object that is being passed out of the business logic layer.

cheers,
barneyb

On Thu, 6 Jan 2005 13:46:11 -0600, Dawson, Michael <[EMAIL PROTECTED]> wrote:
> >>I would generally expect TOs to be effectively read only - an init()
> method and getters (but no setters). I'd be suspicious of code that
> wanted to create a fully populated TO and then mess with its data...
> 
> I think I'm getting more and more confused with the difference between
> beans and transfer objects.
> 
> I have a CFC, which I call a bean (maybe I'm wrong), that has setters
> and getters and validation logic.  This is the one where all the setters
> are string data types.
> 
> Are you saying that once I have the bean fully-populated, I should then
> pass that into a transfer object as a whole, where the transfer object
> then *only* returns data that was passed to it?
> 
> If so, am I wrong in passing a bean directly into a DAO?  Such as:
> 
> Good: Bean --> Transfer Object --> Data Access Object
> Evil: Bean --> Data Access Object
> 
> Maybe I'm just confused on terminology.
> 
> Thanks
> MAD

-- 
Barney Boisvert
[EMAIL PROTECTED]
360.319.6145
http://www.barneyb.com/

Got Gmail? I have 9 invites.
----------------------------------------------------------
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 
www.mail-archive.com/[email protected]

Reply via email to