In real world situations, you're probably going to end up with a mix of both - some freeze dried methods (using a SQL generator, perhaps), and some with variable parameters (using optimized SQL for maximum performance).
And forget gateways. How I wish they were never brought up... ----- Original Message ----- From: Bill Rawlinson <[EMAIL PROTECTED]> Date: Monday, November 15, 2004 1:51 pm Subject: Re: [CFCDev] table DAO > >On Mon, 15 Nov 2004 15:12:48 -0500, Doug Keen > <[EMAIL PROTECTED]> wrote: > > Often, in that situation, I'll actually create different methods for > > different filtering options. For example, I may have a CFC with > these> *public* methods: > > getAll() > > getAllActive() > > getByOwner( ownerID ) > > getAllPrecedingDate( date ) > > > > Those public methods would then simply relay the call to a *private* > > method that contains the SQL and could have an interface like Tim > > describes: > > getAll( condition, order ) > > > > That way, you get the best of both worlds... the caller doesn't know > > about the table structure, but your SQL code is isolated in a single > > private method. The public methods simply relay the appropriate > > information into the private method and return the results. > > > > > I like the look of this particular idea. However, what happens when > you have a very "flexiable" filter.. for instance. > > Lets say you have a bug tracking system. Each bug may (or may not) > have any of the following attributes... > > status (open, closed, resolved, locked, etc) > owner (person bug is assigned to) > submitted by (person who submitted the bug) > submitted date (date bug was created) > category (bug, task, question, etc.) > version (1, 1.1, 2, 2.1) > milestone (release candidate 1, etc) > area (database, user interface, documentation, web services, etc) > > now the user wants to see all open bugs assigned to him. > > you could call getAssignedByStatus(user_id,status) > > but then you might have get all open bugs assigned to bob for the > next milestone > > and this could go on and on - leading you to having all sorts of > method name permutations > > Or, you could have one big method that takes ina bunch of optional > parameters and has a bunch of conditional inclusion of where clauses > and outer joins etc.. > > to date this is the best option i Have found for such dynamic search > mechanisims. Has anyone else found a better solution - and if so how > you would reflect that either in a DAO or a Gateway? > > -- > Bill > http://blog.rawlinson.us > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at www.mail- > [EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at [EMAIL PROTECTED]
