I'm in total agreement regarding maximizing use of the built in
structures such as recordset. I have some similar issues and have used
this approach. Create a method in the DAO (or gateway), called
loadFromRow. It accepts a bean object and a single Row transformed into
a struct. The method loads the bean object just like a single row in a
db is loaded. Why do this? Well in your example you could create 1
bean, call 1 query, loop through the query and each iteration, clear the
local bean, repopulate it w/ loadFromRow and do whatever it is you need
to do before moving to the next record. You accomplish 2 things, 1
minimize unnecessary memory load by using 1 bean and a records and 2
maintain your business needs by only using the bean w/in a look and not
the actual row. Yes you have additional load/processing time but it's
fairly minimal and now you can use your bean as desired.
Robert Munn wrote:
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]
.
--
Jason Daiger
URL: www.jdaiger.com
EML: [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]
