I just named them like that for clarity, hence the comment that follows: "(I'd probably name them differently)"
Baz On Jan 10, 2008 4:19 PM, Derek P. <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
