Hi Aaron, Know how you feel about "master of none". Add CEO, lawyer and salesperson to the list and you've got my core job responsibilities!
I'll be blogging on this kind of Rails style Gateway later in the week (although Rails throws this into their ActiveRecord which seems a little silly to me) in my "Building the Framework" series. I'm going to add getbyAttribute(AttributeName: String, AttributeValue: Any) to my base gateway (BaseGateway.cfc) which all of the other gateways inherit so you never need to write a get by parameter - only extend it. My goal is to make it a public class during initial development for speed and then to make it private, wrapping it with extremely thin generated entity specific methods such as getUserByLastName() or getArticlebyDate() to make the model API more transparent. Best Wishes, Peter -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Roberson Sent: Monday, June 26, 2006 12:07 PM To: CFCDev@cfczone.org Subject: Re: [CFCDev] Question About Invoking/Creating CFC Objects 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 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
