If you create a TO from the main object, then you already have the main
object on the page, obviously.  Why not, then, don't you just use the
getters from the main object?

I'm not saying you are wrong with this implementation, I, too, am
curious as to the "best" solution.

You could store the TO in the session scope as either a very-lightweight
object or just a session-based struct.  Then, if you need to act upon
that data, just pass the struct into another object as needed.

M!ke 

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Dave Merrill
Sent: Wednesday, June 01, 2005 10:10 AM
To: [email protected]
Subject: [CFCDev] Transfer object implementation

In an MVC app, my understanding is that for the view to display the
object's data, the controller typically asks the model for a transfer
object, and passes it to the view. The transfer object is just a struct
containing the model's data.

Given that, you can write a generic getTO method that loops through the
variables scope, and with a little fiddling, builds a struct out of it
and returns it. The fiddling required is skipping all functions, and
'this'.

How about this alternative: Rather than putting all model data directly
in the cfc's variables scope, you put it in a struct, say
variables.instance_data. The getTO method could just return that struct
directly. All getters and setters would need to know about that
implementation detail, but to the outside world, nothing would change.

Comments? Is anyone using anything like either of those generic
approaches?

Alternatives that occur to me are to hard code each getTO method, or
pass the entire object to the view. Neither of those seem terrible, but
they also don't seem as attractive to me. It's of course also possible
that I'm on a completely wrong-headed track here, OO-newb that I am.

Thanks,

Dave Merrill


----------------------------------------------------------
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).

CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm

An archive of the CFCDev list is available at 
www.mail-archive.com/[email protected]


Reply via email to