Hi there,
A few guys have mentioned using factories to provide their DAOs and Gateways, I believe some are also using caching to get maximum performance. Would be great to see how you're doing it. Any chance you could post some code?
Cheers, Pete (aka lad4bear)
----Original Message Follows---- From: "Peter J. Farrell" <[EMAIL PROTECTED]> Reply-To: [email protected] To: [email protected] Subject: Re: [CFCDev] What does a DAO delete method return? Date: Mon, 02 May 2005 13:36:59 -0400
Dave Merrill wrote:
>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?
>
>
I have a hard a time wrapping my head around looking for my single-row delete in my gateway. Although you could argue that depending on preceding logic, your gateway delete might only delete 1 row. My DAOs always have CRUD - create(), read(), update(), delete(). Although, I'm not deleting stuff all that much.
>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?
>
>
Honestly, I don't think it's a great idea. DAOs are used to separate your data persistance layers from your model. It appears that while building the application, this method might save you some time - but maintainence would be a pain. I have enought to remember what to pass in - yet alone column lists etc... Plus, I'm using a factory pattern and abstract classes for my gateways and daos. I like knowing I can call: variables.appConstants.getGatewayFactory().getEamaGateway() and I have my eamaGateway (I'm using Mach-II here...). Plus, I'm passing in objects (beans or TOs)...ah, I think I would go nuts.
-- Peter J. Farrell :: Maestro Publishing
blog :: http://blog.maestropublishing.com email :: [EMAIL PROTECTED]
Create boilerplate beans! Check out the Mach-II Bean Creator - free download. http://blog.maestropublishing.com/mach-ii_beaner.htm
----------------------------------------------------------
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]
---------------------------------------------------------- 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]
