Actually, we have several hundred tables in our data model, fully half of which are complex (read: non-lookup), and a couple million lines of code in our application. It's a true "enterprise" application which has been through several major revisions and employs many different OO patterns and principles, so it's not really a question of scale. It just so happens that our architecture would not benefit from beans. That doesn't mean that they're evil or bad - just that in our case, they're inappropriate for the problems we have to solve.
That's the thing - patterns are meant to solve problems. So if beans don't solve the problem you have, it doesn't matter whether your application is 200 lines long or 2 million - they're not going to help. Roland -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johnson, Ben R. Sent: Tuesday, February 28, 2006 10:46 AM To: '[email protected]' Subject: RE: [CFCDev] Where use getters (not setters - different discussion)? Roland, I'm with you on this one. I like the query object just fine, and if I need additional functionality, I can create a bean for it. But, most of the applications I create are small (less than 20 tables), so perhaps I'm not the best example. Ben -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Roland Collins Sent: Tuesday, February 28, 2006 10:36 AM To: [email protected] Subject: RE: [CFCDev] Where use getters (not setters - different discussion)? 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 :-P ;-)! Most of our objects return queries, even if they're a single row representing a single 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. Roland -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of RADEMAKERS Tanguy Sent: Tuesday, February 28, 2006 9:14 AM To: [email protected] Subject: RE: SPAM-LOW: RE: [CFCDev] Where use getters (not setters - different discussion)? >To draw a parallel, you wouldn't think twice about returning a >dollar value of "3000" from an Product.getValue() call. But >when you display that value, you'll likely want to add a currency >sign and maybe some place denotation, so it looks like "$3,000.00". >You obviously wouldn't want to put the formatting to add the >dollar sign, comma, and decimals in the getter for a price, >otherwise it's useless in calculations since it would be a >string and not a number. Just for fun (and to maybe start another of those monumental back and forth flame war we know and love), may i suggest that you look up an article called "Why getter and setter methods are evil" by Allen Holub. A bit of a contrarian view point, but full of interesting thoughts. Consult a quality search engine. /t ---------------------------------------------------------- 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] ---------------------------------------------------------- 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] ---------------------------------------------------------- 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] ---------------------------------------------------------- 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]
