Barney B, Ya, the thing is, docs in noSql are quite dynamic (no fixed schema) and should be easy to change.
Maybe you're right. When it comes to change, with the Bean/DAO/Service way, I had to change the DAO and Bean, but at least the view layer doesn't have to change, much. With plain old struct, I can minimize the changes of Bean/DAO, and just update the Service layer and 'leak' the change(s) into the View layer. Pick my poison I guess? Henry On Fri, Jan 7, 2011 at 10:49 AM, Barney Boisvert <[email protected]>wrote: > I don't think that a non-sql database and a strongly typed object > model are incompatible at all. Consider a blog (yeah, I know), you > might have blog, author, entry, and comment entities, along with blog, > author, and entry collections in your database. Comments are stored > as an array of subdocuments within the appropriate entry document. > > Regardless of the implementation, your in-memory domain model and your > durable persistence are totally divorced from each other. Or at least > they should be. There's obviously glue code that is implementation > specific for doing persistence operations, but that should be > encapsulated. So aside from that glue code, you shouldn't have to > change much architecturally. > > Obviously if you're looking at some of the large-scale benefits of a > non-sql database (e.g., Couch's autosharding) that's gonig to > influence your application design. But the "non-sql" aspect isn't > doing the influencing - you'd need the same design considerations if > you were using a RDBMS that did autosharding. > > cheers, > barneyb > > On Fri, Jan 7, 2011 at 10:29 AM, Henry <[email protected]> wrote: > > How do you architect the CF backend model w/ NoSQL that are simple, > > flexible, efficient and clean? > > > > Since NoSQL doc has no fixed schema like SQL row, it doesn't really fit > well > > with Objects which are rather static. Therefore the typical > Bean+DAO+Service > > OOP architecture doesn't seem to fit well. > > > > I'm thinking of using plain old Struct's, but then I cannot add behavior > > onto it and it's going to make the whole project very procedural, which > may > > not be a bad thing? > > > > However, if I just use plain old struct, the DB implementations is leaked > > everywhere including the View layer... > > > > Or... shall I translate the array's into CF's Query object for the View > > layer? > > > > Comment? Idea? Suggestion? > > > > Thanks! > > > > p.s. also asked > > here: > http://stackoverflow.com/questions/4622121/nosql-with-coldfusion-beanservicedao-oop-or-good-old-array-struct-procedur > > > > -- > > 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]<cfcdev%[email protected]> > . > > For more options, visit this group at > > http://groups.google.com/group/cfcdev?hl=en. > > > > > > -- > Barney Boisvert > [email protected] > http://www.barneyb.com/ > > -- > 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]<cfcdev%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/cfcdev?hl=en. > > -- 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.
