RE: [CFCDev] Ad-hoc queries using Data Gateway objects

[Jason Daiger]

Title: Spam:RE: [CFCDev] Ad-hoc queries using Data Gateway objects

Essentially just specialized read methods but in practice a Filter object is used most all the time for consistency and code reuse purposes.  I try to think of things in terms of contracts so if the contract for the method warrants use of a Filter Object I use it if not I don't. But again in practice I still use the Filter object in most cases.  A good example where I might not use one is a query that joins 2 or 3 tables and returns many records, such as 'give me all the survey responses for a specific user'.  In that case I might not use the filter since most likely the method only needs 1 value, the user's ID. Now, here comes the but part.  But generally I'd try to design the method or query so that it can do multiple things and hence it gets a Filter object.  E.g. Give me all survey responses b/w 1/1/06 and 1/7/06 or Give me all responses for anyone who said eye color=green are really asking for the same data set and since I'm really doing the same work in any of these cases, i.e. give me responses, I'd design the method to use a filter so I don't repeat the same SQL in several places.     One thing about my Filter objects is they all use default values and the method to which its given (or has a contract w/) says, if it's not the default value use it, otherwise ignore it.    Hope that helps.  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Seth Johnson (KW) Sent: Wednesday, January 11, 2006 2:15 PM To: CFCDev@cfczone.org Subject: RE: [CFCDev] Ad-hoc queries using Data Gateway objects Do you allow a Filter to be passed to all of your Gateway methods, or just to a specialized method?   I was originally planning on having a getUsingFilter() method, but I can see instances where other queries might benefit from a filter.       From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Daiger Sent: Wednesday, January 11, 2006 12:39 PM To: CFCDev@cfczone.org Subject: Spam:RE: [CFCDev] Ad-hoc queries using Data Gateway objects I agree w/ the convention approach over configuration as it adds too many layers.  Also I just reread an earlier post and realized I should have added that each Gateway I use does accept a specialized Filter, e.g. ContactsFilter, which for me is part of the contract b/w the Filter and the Gateway. If the Gateway method chooses to ignore or use only a specific item w/in the Filter I'll add this to the hint for the method so the contract b/w the two is clear.   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Seth Johnson (KW) Sent: Wednesday, January 11, 2006 12:25 PM To: CFCDev@cfczone.org Subject: RE: [CFCDev] Ad-hoc queries using Data Gateway objects > At some point yes a Filter must get mapped to a db column  or column in > order to be used but... It's the DAO or Gateway's job to do the mapping.    I firmly agree,  but there also needs to be a declaration somewhere or what fields or properties the Gateway will accept as a part of a filter.  Otherwise, how do clients know how to construct the filter?   This *could* be done using a mapping file, but the mapping file would be mapping a filter property name (like "name") to the object property it relates to ("firstName"), not the database field holding that data.  As you said, its the Gateway's job to map that object property to its database field (or XML tag or whatever data source the Gateway interfaces with).   I still think I'd choose convention over configuration in this case. ---------------------------------------------------------- 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 ---------------------------------------------------------- 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