I'd like to quickly point out that the concept of 'model' goes far beyond a DAO. There are infinite amount of objects that could/should reside in a model that are not DAO objects.
DW On Jan 10, 2008 5:57 PM, Jaime Metcher <[EMAIL PROTECTED]> wrote: > I have to laugh. Tom, I agree completely with what you're saying. But > isn't it funny how abstractions become concretized and then we find > ourselves wanting to abstract them again. > > DAO = Data Access Object (NOT Database Access Object). The *whole* point > of a DAO, and I've read it on this list a million times, is to abstract data > access so that if your database changes you just change the DAO, not the > rest of the app. So Ray's decided that he wants to use a different > "database" (i.e. for genres it will be a hybrid of the filesystem and a > SQL back end), and our immediate thought (yes, mine too) is "you can't do > that in a DAO!". Well, it's data, and Ray wants to access it. What kind of > object would that be? Maybe nobody else finds this funny. > > As I say, I'm not disagreeing - this idea that DAO = SQL database wrapper > is so entrenched that it would be asking for trouble to buck the trend. It > is a nice example, though, of how abstractions evaporate over time. Or > maybe it's the leaks - the underlying detail of a leaky abstraction > eventually leaks into the abstraction and sinks it. > > To wax even more philosophical, I think this is why, wearisome as it is, > language design is so important. If you ever had a language where you > didn't have to short-change your object model to get around language > limitations, abstractions wouldn't leak so much, they'd float for much > longer, and we would just use them without thinking. In this light, the > idea that "ORM is computer science's Vietnam war" doesn't sound so > melodramatic. > > Jaime > > -----Original Message----- > *From:* [email protected] [mailto:[EMAIL PROTECTED] Behalf > Of *Tom McNeer > *Sent:* Friday, 11 January 2008 6:49 AM > *To:* [email protected] > *Subject:* [CFCDEV] Re: Placement of non-db related code and MVC > > Well, the model *is* the business - RioGrande. And part of the business > involves uploading those files. So there's certainly nothing wrong with > doing it in the model -- that's where it should be done. > > But *not* in your genre DAO. Something else -- like a GenreService or a > smart Genre object, depending on your architectural preference, should > handle both saving the database information (through your DAO) and writing > the file. > > > > -- > Thanks, > > Tom > > Tom McNeer > MediumCool > http://www.mediumcool.com > 1735 Johnson Road NE > Atlanta, GA 30306 > 404.589.0560 > > -- "Come to the edge, he said. They said: We are afraid. Come to the edge, he said. They came. He pushed them and they flew." Guillaume Apollinaire quotes --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
