I'll try to continue the discussion here so as to not hijack the other post :)
What you both said makes perfect sense to me, and thank you for the extremely detailed explanations! I have to say that in my context (Mach-II user) that using TOs seems to make more sense than writing Beans. The BeanCreator is a useful tool, but the very fact that it had to be written to alleviate writing repetitive get/sets seems to indicate (IMHO) that maybe there's a better way of approaching this data transfer problem. The power of the bean (again IMHO) is in the validate() method that's specific to data being modeled by the bean. However I think that you could so something similar with TOs.. Why not just write what I'll call TransferObjectValidator classes instead? It has a single method, validate() that takes a TO as the lone argument. For each TOV that you write, just implement the custom validation logic needed for the particular type of data being modeled, and it just returns true or false as to whether or not the TO passes the validation rules being defined? At least to be, that seems to make more sense... we're bundling some generic set of data into a TO, and then asking whether or not the TO conforms to a particular set of rules. So instead of having 10 beans in an app with lots of set/get code and a validate() method each , we have a single TO and then 10 TOVs that implement the validation logic necessary for the TO to move "deeper" into the app where the business logic components actually start to do something with it. Maybe I'm missing something critical here since the sun is rising and I haven't been to bed yet :) At least to me, it seems like this technique would probably shrink the quantity of code written to deal with data transfer by a significant amount. Let me know what you guys think :) -Cliff On 5/8/05, Peter J. Farrell <[EMAIL PROTECTED]> wrote: > Peter J. Farrell wrote: > Beans (aka value object) and Transfer Objects (TOs) are all types of > transfer objects. I've coined the term Lightweight Transfer Objects (LTOs) > lately because not the a traditional TOs object as defined in the java docs, > but almost sort of like an encapsulated transfer structure. > > Revision... > LTOs use the THIS scope which is a public scope and can be modified outside > of the CFC. LTOs are not fully encapsulated...but quasi-encapsulated as I > hope the developer would refrain from changing the data inside the LTO after > its' init(). Any changes to data should be done on a bean not on the LTO. > LTOs are meant to be read-only. > > As you can see, I'm not a technical writer... > -- > Peter J. Farrell :: Maestro Publishing > > blog :: http://blog.maestropublishing.com > email :: [EMAIL PROTECTED] > > Create boilerplate beans! > Check out the Mach-II Bean Creator - free download. > http://blog.maestropublishing.com/mach-ii_beaner.htm > > Not a computer nerd; merely a techno-weenie. > > -- > ---------------------------------------------------------- > 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] ---------------------------------------------------------- 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]
