> I'd put single row updates / deletes in a DAO and mult-row > updates / deletes > into a Gateway object. For some data I might have a DAO, others > a Gateway > or even both a DAO and a Gateway but it depends on the situation. > For me, it keeps things simple. > [...] > Cheers, Pete (aka lad4bear)
This brings up another question, how generic should these methods be? For instance, my current single-table sql delete method deletes where pk in (#pks_to_delete#). That's how I'd expect a multi-row delete would *have* to be written, but it works fine for the special case where there's only one item in pks_to_delete. Would you actually create two methods for this, one in your DAO and one in your DG? On another level, my current thinking is that all DAOs inherit from a base DAO class, which contains generic parameterized versions of some common methods. Instead of writing a delete method from scratch, for instance, an area's DAO can use this inherited method, passing it the arguments from, pk_col_name, and pk_list. Similarly, a generic single-table save method can manage both inserts and updates, based on passed arguments. If things are unusual or more complex, the area's DAO can skip these generic tools and use its own ad hoc method. What do folks think about this? (And thanks again for all the comments. I hope that down the road, other people thinking about these issues will find all your responses useful.) Dave Merrill ---------------------------------------------------------- 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]
