Right, but my point is that we then have two options. Lets say I need to DateFormat(User.DateofBirth,"MM/DD/YY") for whatever reason.
If I write code in the DAO (or Gateway if you use one for dealing with n-record returns) to transform User.DateofBirth, shouldn't I use the same code to change the format of a single record being returned as a bean from the DAO as well? The primary argument for getters/accessors in beans (setters/mutators are a whole different story) is to allow for such transformations within the getter methods. But if I put such transformations on my beans, I am violating DRY (don't repeat yourself) by putting the same transformation in both my Gateway and bean. If I keep the code in one place (in my app it would be in the DAO which is capable of transforming 1..n records), then what is the need for getters? Why not just (read) access the property using the User.FirstName property instead of the User.getFirstName() accessor? The only way I could keep non-trivial getters and avoid repeating every single transformation in two different code bases would be by always returning recordsets as collections of beans which seems impractical from a performance perspective. Am I missing anything? Best Wishes, Peter -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Munn Sent: Monday, February 27, 2006 11:03 PM To: [email protected] Subject: SPAM-LOW: RE: [CFCDev] Where use getters (not setters - different discussion)? I don't see a lot of value in putting a recordset through a bean, I don't think that's what beans are for. I could see value in doing something to the recordset , but languages have recordsets, cursors, and other similar structural components for good reasons including ease of use and performance. if you want to operate on a column in a recordset, there are lots of ways you can do that in CF,and if you had a common set of transformations you wanted to make, I suppose you could package them all up in a component and pass the recordset into it. I guess it depends on when and where you need to perform the tranformation. if you only need the data transformed at display time, just use the recordset iterator and perform the operation at that point. -----Original Message----- From: "Peter Bell"<[EMAIL PROTECTED]> Sent: 2/27/06 11:06:29 AM To: "[email protected]"<[email protected]> Subject: [CFCDev] Where use getters (not setters - different discussion)? A slightly different angle on a very old debate. I think we all agree that getters allow for abstracting the process of returning a value. Today getProperty just returns the value, tomorrow it might do a transformation or calculation, so using the getter stops that from breaking code in other objects. They also add some value in terms of introspection (you can see a list of methods of a class which helps when reusing components). Getters don't hide data per se (only the method of creating the data) as whether you have a reference to customer.FirstName or customer.getFirstName() in both cases you are assuming there is a first name and if that assumption changes your calling object will break - that's just life. But here is a question. Lets say you are working with queries using a gateway. You probably don't want to instantiate a bean for every single item in a list of 200 records, but you still want to be able to display FirstName. If you add a transformation or a calculation to getFirstName in the bean, you ALSO need to add it somewhere in your business layer that interacts with the Gateway for displaying queries. This seems like repeating ourselves, so I'm wondering if it wouldn't be better to put that logic further back into the business layer which can operate on both lists of customers (using an iterator) and on a single customer before creating the bean (BTW do you usually put that kind of business logic into a Gateway? where could such logic go?). But if we go that way then the getter will NEVER do anything more than just set a value, so you could replace the bean with a struct or a simple object with direct access to the variables and the only thing you'd be losing was the introspection capabilities (which don't matter to us in this case as we active generate the code anyway). Looking forward to someone who's been thinking about this more than a few weeks to highlight the blindingly obvious point I'm probably missing! Best Wishes, Peter ---------------------------------------------------------- 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 (wwwcfxhosting.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]
