I discovered that my database needed to be redesigned and now it
requires two different methods anyways (getProductsByCat and
getProductsByFormat).
It's always fun being the server administrator, db designer and
administrator, web designer and developer, etc. etc. I often feel like
a "jack of all trades, and a master of none!"
Thanks again guys,
Aaron
On 6/23/06, Peter Bell <[EMAIL PROTECTED]> wrote:
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
----------------------------------------------------------
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]
