Isaac,
A quick comment on your CFC snippet...
First of all, thanks for using real code instead of psuedo-code. I
know sometimes the shorthand is nice for the writer, but it's hell on
the reader. I do it myself, although lately I've been more inclined to
jump into HomeSite+ and write it up and then copy/paste. It's actually
faster that way than sending pseudo-code, more accurate, can be
tested, and gives the reader the ability to copy/paste themselves and
run the code.
But, I do see you're using NOT isDefined("variables.var"). I've been
using NOT structKeyExists(variables,"varName") (which I didn't know
about until Sean yelled at me for using the other method... ;) )
and I can say that it dramatically improves clarity, performance, and
readability. It doesn't use the isDefined() search path, it checks the
scope (or any struct you specify, actually) and immediately reports an
answer.
I've noticed improvements of up to 50-60% in response times for
pages/code that are dependent on the isDefined/structKeyExists check
process.
Just FYI.
</comments destination="S. Isaac Dealey">
As far as the original question... I've got one situation where I'm doing this:
<cfset var returnData = structNew()>
<cfstoredprocedure...>
<cfprocresult name="returnData.descriptor" resultset="1" />
<cfprocresult name="returnData.columns" resultset="2" />
</cfstoredprocedure>
<cfreturn returnData />
I don't see a reason to split them up. If the stored procedure is a
unified method for accessing data, and the data is always going to be
returned in a block, why on earth would it make sense to divide them
up into many getters/setters? I can see this making sense in
situations where you may or may not return all the data from an sproc
call, but in my case I'm *always* going to return *all* the result
sets. It's not better encapsulation to divide it, IMO, in this case...
it's a waste of effort.
My other question is this: Why would you write an sproc that returns
more data than you need? That's another waste of resources. I would
also submit that it's a symptom of low cohesion. If your needs are
such that an sproc is required and the results are variable, I'd use
internal logic in the sproc to return the data that's necessary.
Now, I can see situations wherein you may have a CFC in a shared scope
that contains query data in it's instance data... if you don't need
all the data all the time but are going to need it at various points,
sure, that makes sense. getDataThis() and getDataThat() would be
sensible. If we're talking about a DAO/Gateway that deals with data
processing for an event, that's where I have questions... I'm mostly
wondering "why would you want to do that anyway?"
Laterz,
J
On Thu, 3 Mar 2005 15:59:36 -0500, S. Isaac Dealey <[EMAIL PROTECTED]> wrote:
> > I think for readability returning the values in a
> > structure is going
> > to do a.k.a S.Isaac
>
> > <cfset data = myCFC.getQueries()>
> > <cfloop query="data.getUsers">...</cfloop>
> > <cfloop query="data.getRoles">...</cfloop>
>
> > But the idea of going through a function to get the
> > different
> > recordsets, and referencing via the array would mean that
> > there is no
> > need to know the name of the queries? defently beneficial.
>
> > Cheers everyone for you help
>
> Another option is if your object has persistence and that persistence
> is maintained via a caching mechanism, that you could simply execute
> the stored procedure on an as-needs basis, and then use separate
> methods to return the individual record-sets from the stored
> procedure... as an example:
>
--
Continuum Media Group LLC
Burnsville, MN 55337
http://www.web-relevant.com
http://cfobjective.neo.servequake.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Logware (www.logware.us): a new and convenient web-based time tracking
application. Start tracking and documenting hours spent on a project or with a
client with Logware today. Try it for free with a 15 day trial account.
http://www.houseoffusion.com/banners/view.cfm?bannerid=67
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:197383
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
