and not "any" aspect of it.
I prefer the bean idea almost exclusively. I like the fact that I can encapsulate all of my logic pertaining to some aspect of my model in one object (definition, validation, etc). When debugging I know exactly what file to go to.
I only use a LTO type thing if I am dealing with a remote caller scenario that just needs to consume my data.
Having to write Getters and Setters is a tedious process - but being tedious doesn't mean its a bad thing. It protects your data in a readonly state so that the only way it can be modified is via the setter. I like the explicit nature of the Beans mutator methods.
There are alot of actions in software development that can be tedious. Its why so many tools are developed. THe mach-ii beaner is a fine tool to help you rapidly develop using very valid design pattern. Dont let seeming redundancy and tedium turn you away from using discreate objects to represent your model.
The single TO idea that changes it's definition based on the context your using it just bothers me. I'm having trouble expressing why it bothers me - but it does. However, on the flip side, I can see how it would work. It just seems "messy" to me.
On 5/8/05, Cliff Meyers <[EMAIL PROTECTED]> wrote:
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]
--
[EMAIL PROTECTED]
http://blog.rawlinson.us
If you want Gmail - just ask. ----------------------------------------------------------
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]
