yes I agree completely you need to have really good seperation on large apps, or I can assume so anyway, hehe. So the getAll(condition,order) approach definately isn't an ideal situation to reducing complexity, and not to mention the performance issues ;)
TiM -----Original Message----- From: Doug Keen [mailto:[EMAIL PROTECTED] Sent: Tuesday, 16 November 2004 9:29 a.m. To: [EMAIL PROTECTED] Subject: Re: [CFCDev] table DAO Like most things, I bet it depends on the complexity of the application. The app I'm working on is massive... I can't imagine the chaos that would occur if we used a getAll(condition,order) approach and we changed the DB structure around a little bit... we'd have to change all the arguments for those methods across the app! To mitigate that, we put in some extra effort to abstract filtering and sorting logic into separate Gateway methods. The method name indicates *what* you're doing, and the method implementation indicates *how* it gets done. You end up with more methods (and some more code), but the impact of change is much less far-reaching, since the *what* isn't all that likely to change, but the *how* part is. If you're working on a smaller app that isn't likely to change all that much, then I'd agree... that level of abstraction is probably just creating extra work with little benefit. It's a trade-off (isn't everything a trade-off?). On Tue, 16 Nov 2004 09:17:58 +1300, Tim Van Der Hulst <[EMAIL PROTECTED]> wrote: > getAllActive() > getByOwner( ownerID ) > getAllPrecedingDate( date ) > > oh yep avoid that stuff like the plague. haha my early DAO's were like that > before I realised all I needed was the one base DAO and the very occasional > need to create a specialised subclassed DAO. Mind you in saying that I still > haven't really tackled multiple tables/joins yet tho. > > > > TiM > > -----Original Message----- > From: Doug Keen [mailto:[EMAIL PROTECTED] > Sent: Tuesday, 16 November 2004 9:13 a.m. > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] table DAO > > > Ok then - so that brings up -another- question. getAll by itself, IS rare. > > Most of the time I'm doing getAll where Active=1, or getAll where Owner=Me, > > or some such. So if we have a Gateway CFC to handle getting a bunch of crap, > > where do we put filters? That's business logic - and it seems like it would > > make sense in the core CFC for the datatype. > > 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. > ---------------------------------------------------------- > 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] > ## > ## > ---------------------------------------------------------- > 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] > ---------------------------------------------------------- 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] ## ## ---------------------------------------------------------- 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]
