Hooray for not reading the whole message, heh. On Jan 10, 2008, at 4:23 PM, Baz wrote:
> 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 -~----------~----~----~----~------~----~------~--~---
