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
