Well, I certainly wouldn't use a query object. I'm not a fan as there is no possibility of encapsulation of any possibly business logic.
These days, I don't like the IBO too much either. I always knew it was violating the Single Responsibility Principle by being both an object and an iterator, but it worked pragmatically so I used it. These days, I usually create an Iterator which returns an object, but instead of creating an array of object and wrapping them in an iterator I always return the same object, but loaded with different state. I would definitely recommend objects for all the usual reasons (unless you believe you're always going to be doing pure dumping of data to the screen with no business logic at all). Best Wishes, Peter On Jan 7, 2011, at 1:58 PM, Henry Ho wrote: > 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]. > >> 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]. > > 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. > > > > -- > 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. -- 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.
