A bean is basically pretty small by definition - and often times you may not have a reason to support TOs at all within your system - however
if you want an even lighterweight object that contains the data without any extraneous methods then a TO fits the bill.
One example where this is useful is if you have a distributed system where you just need to pass data from point A to B. Point B is responsible merely for the display of said data and not for the gathering or modification of it.
It really depends on what your trying to do.
For instance, I have an issue tracking application that has at least two screens in it that deal with showing an issues contents:
1. editing an issue - populates the form with the issues information
2. display the issue - a readonly view of the issue.
when you load either of these pages they make a call to the issue subsystem that returns a TO - i have no need for setters or any kind of data validation here - I know that what I'm getting is already validated and I just want to display it.
Now, once the issue has been edited and the form has been submitted, I would populate a bean, validate it, and if all was good, pass it on to a DAO for saving but I don't call for Bean until I actually need that heavy of an object. (and even then the bean is pretty light).
This comes in handy mostly when a remote view is calling for the Issue information. It really doesn't make too much difference if everything is local or if there is little system usage going on. But for larger systems with heavy traffic - well a TO can really save you alot of bandwidth, resources, etc over a cumulative time.
If your bean is really trivial, say just two or three properties - it probably doesn't matter and adding a TO is overkill - but if you have ten or more properties to your Bean then it might be a good idea to have a TO. Really it is something that needs to be evaluated for each project and its requirements.
Bill
On Apr 1, 2005 9:44 AM, Mike Kear <[EMAIL PROTECTED]> wrote:
Thanks Bill, I'm sorry if I sounded rude. I didn't mean to. It's
very difficult for me to make sense of the maze of terminology. I
never know whether a term I dont understand is a technical term I have
to learn, or just a metaphor someone invented to give a little more
colour to the language. And more often than not, looking up the
term in somewhere adds half a dozen new terms to the list that I also
have to look up in order to understand the first term. But of course
the definitions of those terms also includes half a dozen new terms
.... you get the idea..
Anyway ....
I thought a 'bean' was the lowest level of building block in an OO
application. If a bean already has the data included in it, why also
have a transfer object? What does it do that a bean doesnt?
I thought the idea was a 'bean' was the smallest building block,
containing the data relating to one object (one person, one job, one
record, whatever) and a DAO object handled the traffic of that data to
and from the data storage. How does this relate to transfer objects
or do TOs belong in a totally different scenario?
Cheers
Mike Kear
Windsor, NSW, Australia
Certified Advanced ColdFusion Developer
AFP Webworks
http://afpwebworks.com
ColdFusion, PHP, ASP, ASP.NET hosting from AUD$15/month
On Apr 2, 2005 12:16 AM, Bill Rawlinson <[EMAIL PROTECTED]> wrote:
> MIke,
> Im sorry I added clouds to the conversation for you. I really didn't
> intended to; and I was kind of hoping you would ignore the other comments
> that dealt with the "graph" stuff.
>
> Ok. I'll try to explain it, and then, I figure someone who knows more will
> jump in and clean up the mess I cause :O)
>
>
> To me a transfer object is a light version of a bean. A bean has a bunch of
> properties with getter and setter methods - once passed around it is both
> readable and writable by using the getter and setter methods. A bean might
> also have some validation routine(s) within it.
>
> A transfer object on the other hand should be treated as readonly once it
> has been initialized. It doesn't carry around any setters or any validation
> logic at all - it just carries around data. Basically, it is a readonly
> STRUCT with a specific definition (you can't add new keys to it once it's
> instantiated).
>
> Serializable in the simplest terms is kind of like converting an object into
> a string in such a way that the process can be reveresed so that the string
> can be deserialized back into its originating object form.
>
> A mutable object has components/properties that can be modified (via set
> accessors) once the object has been created (mutation) Therefore a bean is
> mutable, a TO is not.
>
>
> Hope that helps
>
> Bill
>
----------------------------------------------------------
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]
--
[EMAIL PROTECTED]
http://blog.rawlinson.us
I have 47! gmail invites,want one? ----------------------------------------------------------
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]
