Its interesting that you prefix them all with Dao, is there any reason? I would think you'd have a User object and then a UserDB, UserLDAP, UserFS, etc.
On Jan 10, 2008, at 4:06 PM, Baz wrote: > 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 -~----------~----~----~----~------~----~------~--~---
