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]
