I ran into a similar situation recently where I had a USER business object that partly gets populated from an SQL DB and partly from our LDAP. I decided to make the read() function of my DAO interact with both my database and the ldap to populate my business object - and it's working very well for me - because any adjustments I have to make are nicely localized. The rest of the model simply says "populate my USER object" and the DAO does the rest. As long as I return a populated DAO everyone is happy.
One thing I may do, depending on how complicated things get, is to compose my DAO of other objects that specialize in each piece, such as: UserDaoDB, UserDaoLDAP, UserDaoFileSystem (I'd probably name them differently) but thats more of a code organization concern because the primary UserDAO would be the only entry point to those other objects by the rest of the model. Cheers, Baz On Jan 10, 2008 3:48 PM, Derek P. <[EMAIL PROTECTED]> wrote: > I feel like getting made fun of, so I'll put my two cents in. > > Discussing a Model and a DAO interchangeably is sort of an interesting > idea. If we were thinking in terms of a Genre object like Ray seems to be in > his examples, It makes perfect sense to me to have the upload process be > part of his Genre object. Now, if his Genre also implemented some > functionality (say it extended the "BaseDAO" class) that allowed it do do > all the CRUD stuff autonomously, you could just implement specialty > functionality like uploading by implementing your own create() or save() > function that references the parent's abilities and does your special need > (like an upload). > > there is a lot of focus in CF about having Data Access Objects that are > these (in their own right) autonomous, slightly specific, database access > objects that don't seem to really provide you a lot of functionality. > > ...or maybe I am missing something. > > > On Jan 10, 2008, at 3:32 PM, Tom McNeer wrote: > > I don't think there are actually any disagreements here. Dan's exactly > right, and that's what Jaime and I are saying. > > And yes, Jaime, I did allow myself to leap to the usual CFer's > interpretation of a DAO, against which Sean Corfield rails mightily, > frequently, and correctly. But I think including filesystem work as part of > a DAO (regardless of acronym interpretation) is a bit of a stretch. Of > course, that's exactly what you were doing: stretching on purpose, to make > the point. > > Besides, Ray Camden started this thread. I'm just happy I can even comment > in a thread of his, and I doubt seriously I have anything to teach him about > design patterns. > > And as far as ORMs go: yes, I find I get some interesting comments from > time to time when I explain why I like using Transfer. Not actual combat > exactly, but ... > > > > -- > Thanks, > > Tom > > Tom McNeer > MediumCool > http://www.mediumcool.com > 1735 Johnson Road NE > Atlanta, GA 30306 > 404.589.0560 > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
