> Patrick Said...
> That may be true. I doubt that I know any more about it than you do,
> but it doesn't make any sense to me. Isn't a DAO supposed to abstract
> away the storage mechansim? What if  you're storing objects in an OODB
> or an XML file? They don't even have rows.
> 


True, but I would probably have a genericDAO and then more storage
mechanism specifc ones.  So then maybe my odbcCertificateDAO would
deal with the referential mechanisms and my xmlCertificateDAO would
deal with them differently.

It is exactly this abstraction away that makes me wonder where the
best place to put the added query/process (to remove the references).


>Chris said
>Maybe turn this around a bit - what is going to expire the certificate?
> Some sort of scheduled task?  Perhaps provide a method on the
>CertificateGateway to fetch expired certificate PKs, then loop
>instantiating an array of certificates, and expire as above.

In the examples I am thinking of there is a user driven means to
remove these referenced objects (whether they be Certificates,
Categorizations, de.licio.us tags, GradeLevels, etc)

Maybe, since the delete method really effects multiple rows it should
go in the CertificateGateway - but that seems like it would be
confusing to later developers who would expect the D in CRUD to be in
the DAO.

I encounter decisions like this all the time and typically by writing
the problem down in english like we are the answer becomes  apparent -
unfortunately this one isn't.

So far the "best" seeming answer I keep coming back to is to put the
odd query in the DAO.


Thanks to all of you for giving this some thought and sharing your ideas

Bill
----------------------------------------------------------
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-archive.com/[email protected]

Reply via email to