Hi There, Good point. Dateformat would be a bad example. But replace the example with any valid business level transformation and the core point still stands. If you have transformation logic in beans, you must either turn all query lists into collections of beans to implement the same logic (a performance problem) or you need to duplicate the code elsewhere (say in your Gateway). But if you have a DAO that handles both individual items and lists with that code, there's nothing left to go into the bean accessors so get#PropertyName#() getters don't seem to have a valid use case that I can think of.
Does that make sense? Best Wishes, Peter -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roland Collins Sent: Tuesday, February 28, 2006 12:41 AM To: CFCDev@cfczone.org Subject: SPAM-LOW: RE: SPAM-LOW: RE: [CFCDev] Where use getters (not setters - different discussion)? Date formatting is display logic, and therefore belongs in your display layer. As long as the data layer returns a type of "date" (or something resembling one CF since CF is type-less), it's up to your display layer how it is to be formatted. 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. So why would you do that for a date? Dates are a (pseudo) low level data type just like numbers, after all - at least as far as CF is concerned :) RC -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Bell Sent: Monday, February 27, 2006 11:07 PM To: CFCDev@cfczone.org Subject: RE: SPAM-LOW: RE: [CFCDev] Where use getters (not setters - different discussion)? 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: CFCDev@cfczone.org 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: "CFCDev@cfczone.org"<CFCDev@cfczone.org> 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 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 (wwwcfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org ---------------------------------------------------------- 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 ---------------------------------------------------------- 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 ---------------------------------------------------------- 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 ---------------------------------------------------------- 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
