Peter, I was doing query with NoSQL yesterday. The result set is array of structs. Then it reminded me of the IBO pattern that you introduced to me. :)
Do you think this is a good use case to wrap the array of structs into an IBO? Maybe that's a better approach to.. translating an array (MongoDB query result set array) into a query object? Henry On Fri, Jan 7, 2011 at 10:51 AM, Peter Bell <[email protected]> wrote: > The one difference is that many NoSQL stores don't have a fixed schema, so > you have the option of having arbitrary properties. That's what I'd handle > with oMM() > > On Jan 7, 2011, at 1:49 PM, Barney Boisvert 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]<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.
