Hi Aaron,
I'm not a fan of a method arbitrarily pulling by category or by format (i.e.
just two of the n possible parameters).
For a production application, I would do the extra typing and have a
getProductListByCategory(CategoryID: int) and
getProductListByFormat(FormatID: int). If you didn't want to have the two,
I'd have a getProductListByParameter(ParameterName: string, ParameterValue:
any) that would allow you Rails style to
getProductListByParameter("Category", 7) or
getProductListByParameter("Format", 12) or even
getProductListByParameter("Price", 10) or getProductListByParameter("Title",
"My Product") if you so wished.
The naïve implementation is a cfquery with a
SELECT %FieldNameList%
FROM %TableName%
WHERE %Parameter% = %Value%
ORDER BY %OrderBy%
- This assumes the value is safe (so don't - put a cfqueryparam which then
needs to be conditional based on the data type of the parameters so your
method needs to know this via introspection or if necessary a hard coded or
generated lookup table)
- This assumes you're pulling from a single table or a view pretending to be
a single table
- This assumes you're not using a Stored Procedure
- This assumes the parameter is a valid field name in the table so you
either only want to call this very carefully or want to do some database
introspection on instantiation of your gateway to pick up a valid list of
field names.
- This also assumes your parameters don't need aliased. If you have field
names like STR_OLD_MYFIELDNAME_USR4 for the user address, you'd probably
also want to put an alias lookup into your service so the gateways and DAOs
could accept aliased parameters. Aliases are also good as one form of
dependency people seldom talk about is that most applications have variable
names tied to the name of the database fields. This is an efficient
convention, but means that changes to your database naming will often break
your code. An alias table in your service layer is a good (if heavyweight)
solution to that problem. As with anything else, don't throw it in unless
it's likely to be a problem - You probably Aren't Going To Need It.
I'm not a big fan of rails style parameter/value calls as they hide
dependencies in most cases. It's more typing to create a method for each
field you may query by, but it makes it clear that your application is
depending on those fields and their data types, so you're less likely to
break your code accidentally when refactoring your db schema.
Best Wishes,
Peter
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Aaron Roberson
Sent: Friday, June 23, 2006 4:37 PM
To: CFCDev@cfczone.org
Subject: Re: [CFCDev] Question About Invoking/Creating CFC Objects
In my gateway I have a method which accepts two arguments. The query selects
products by category (if catID NEQ 0) or by format (if formatID NEQ 0). I
originally had two methods, but I thought that with a little conditional
logic I could make one method. My thinking was better code reuse, but this
is all still new to me so for all I know I should take it back to two
methods.
Any suggestions?
-Aaron
On 6/23/06, Nolan Erck <[EMAIL PROTECTED]> wrote:
> Same answer as the Val() question -- it's something I've used here and
> there, but I don't make it a regular habit, moreso something I have to
> use from time to time based on the application/framework I'm dealing
> with. Your mileage may vary. :)
>
>
>
> Nolan Erck
> Web Developer/Programmer
> Schools Financial Credit Union
> (916) 569-5409 Office
> (916) 569-2024 Fax
> www.schools.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
