Peter:  thanks for the in-depth reply!

>>This is actually been an oft discussed topic on this list and the 
>>answers that have come up have caused quite a bit of confusion at 
>>times between the differences between the two object types.
>
> Agreed! 

That's obvious from the archives... I did a search before posting, there
were over **600** messages that include the word "bean".  Over 300
included "bean" and "object" together.  (Unfortunately, without a way to
search the subject line only I couldn't separate the wheat from the
chaff, so here we are again :)


(reply edited for space)
> Here's example of how I use a bean/LTO:
> form/user input 
> --> set values to bean 
> --> pass in error handling object to validate() 
> --> validate bean and return errorHandler 
> --> logic... 
> --> if no errors, myBean.getLTO --> pass LTO to DAO 

If a "bean" us already a lightweight object, offering only a few getters
and setters, is there really a compelling reason to generate a LTO for
passing to the DAO, instead of just passing the bean itself?


> My beans now almost all "loosely" typed (strings) 
> while my LTOs are "strongly" typed (string, date, 
> numeric).

So what happens when SomeComponent.cfc wants to use the data from
SomeBean?  Does SomeComponent need to determine the data type of the
return value before using it?  Isn't the primary benefit of a strongly
typed design the AVOIDANCE of data type ambiguity?  (I'm not attacking
you, just trying to understand)

Do you ever create strongly typed objects to represent fully formed,
validated beans?  For example, using CustomerBean.cfc to handle the data
validation then using Customer.cfc to hold a valid object with strongly
typed return values?


> check out Rooibos Generator 

That's one of the tools that prompted my question :)  (Side question:
your blog entry on Sept 14 mentions releasing the source code... Are you
still planning to do that?  I'm building my own CFC generator to add
some features specific to my organization, I'd much rather extend
Rooibos than start from scratch)



----------------------------------------------------------
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]


Reply via email to