>Actually, I don't use beans at all in CF (with the rare >exception of some web services that have interop requirements), >so I don't use bean getters and setters - no flame war for you >queries, even if they're a single row representing a single >:-P ;-)! Most of our objects return data entity. >The query dot-notation is wonderfully elegant, and the native >manipulation operations that CF provides are too much to pass up. >Beans add a layer of complexity and overhead in our instance >that just isn't warranted. And honestly, in most cases, I >think beans are overkill. There *are* many problems that >beans can solve fairly elegantly, but just like everything >else, they should be implemented to solve a problem, not >just because they're en vogue.
I was thinking more specifically about the section entitled "Draw thyself", where he argues that it's better (going back to our example of Product.getValue() -> 3000 vs "$3,000.00") to have a Product.renderValueAmount() call that either a) returns the string "$3,000.00" (or else b) returns a component instance capable of rendering this value) rather than doing the more usual: <cfset amount = Product.getValue()> <cfoutput>#DollarFormat(amount)#</cfoutput> because if Product.getValue() ever changes to return anything other than a number, then boy are you going to have fun tracking down all the calls made to that function and wrapping/hacking the subsequent ops made on that value. There. That should get me my flame war ;) /t ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
