And just to pipe in, this is *exactly* what an Iterating Business Object was designed to solve. If you have dumb lists, use queries. If you have collections of business objects with meaningful business logic, use an IBO to encapsulate that. That way you use the same logic for 1 bean or 1,000 but are only instantiating one object so performance is never an issue,
Best Wishes, Peter On Aug 29, 2009, at Sat Aug 29, 12:34 AM, Matthew Woodward wrote: > To answer the question in the subject: it depends. > > Brian H. wrote: >> It always seemed to me that if you went through all the trouble of >> writing beans and DAOs, that you should be able to grab an array of >> beans and use those objects in the “listing” page. > > You can certainly do this. > >> Let’s forget any CF object instantiation performance concerns for the >> moment and focus on core patterns. > > Ah, but you can't forget performance. Doesn't mean you CAN'T do > this, but you need to always be aware of how much data your app will > eventually be dealing with. > > Short answer is that in Java you don't have to worry about this > because Java is so insanely fast compared to CFML when it comes to > objects. > > That being said, it really just depends on how much data you're > talking about, and the performance impact weighed against a > realistic assessment of how your application handles data will > determine what you can and can't get away with. > >> Here’s my problem. Let’s say that I >> am on a user listing page, and I want to loop over an array of user >> beans, outputting values by calling “getter” methods. Along with >> simple Name and contact info, I also want to pull the names of all >> projects this user is assigned to. This is obviously not something >> typically stored in user bean. I obviously don’t want to have to >> instantiate whole project beans and compose them within the user bean >> every time that I load up a user since that is pretty wasteful. > > But if we're forgetting about performance concerns and just looking > at it from an object modeling standpoint that scenario makes perfect > sense. > >> Have I totally lost my mind in wanting to use arrays of beans instead >> of queries for my listing pages? Especially since my beans do all >> kinds of wonderful formatting for me like “getPhone()” and >> “getPhoneFormatted()”. > > You haven't lost your mind, but you have to make the right decision > on a case-by-case basis. If it's not much data we're talking about, > great; I built an entire app this way and since it wasn't much data > it worked great. Until the client called a year later and said, "You > know those collections I told you would never consist of more than > 4-6 objects? Well now we have one with 130 objects and it's running > kind of slow." :-) > > Point being there's your ideal object model, and there's reality, > and reality can bite you a lot more quickly in CFML because of the > overhead associated with instantiating objects. > >> I expect that the responses I’ll get here are going to be “well, that >> is WHY you are supposed to use a gateway to return the listing as a >> query, so you can pull all this cross-referenced data from the DB >> directly”. Yes I know, but doesn’t it seem like an awful waste of all >> that bean/DAO programming? > > Well, yes and no--again, depends on the app. Would I write a > reporting application using objects? Heck no--queries are great for > reporting-type data, so it likely wouldn't make sense to use a bunch > of objects in that case. Would I write a banking app and not use > objects? Again, heck no--having an "Account" object and a "Customer" > object just makes way too much sense. > >> I love the fact that my bean can have a “getPhone()” and >> “getPhoneFormatted()” method. I can even pass my bean a >> “PhoneFormatter” component to do the formatting. Now it feels like >> that I have to repeat all of this work when pulling “listings” as >> simple CF queries. > > Well there's are some happy mediums here. The reality of life in > CFML is queries are fast, huge collections of objects are slow. > That's life. If you want wicked fast performance with tons of > objects, you need to write your model in Java. > > The other thing to remember is that listings are what query objects > are for, so if you're avoiding them for some weird sense of "but I'm > not 'doing OO'" (whatever that means), then don't. Smart programmers > use the right tool for the job as opposed to blindly following some > arbitrary set of so-called rules they think they should be following. > > So stepping off my soap box, you want object-like functionality but > need speed for large collections? Use structs. In most of my beans I > have a getMemento() method that returns the variables scope so I get > the data from my beans without all the overhead. It's a great > compromise. > >> Anyway, sorry for the long winded post. Just feeling a bit >> frustrated >> here at seeing what feels like an elegant architecture go to waste. > > I don't think it's a waste--even if you use it rather sparingly in > your application it leads to a much more maintainable app in my > opinion. Otherwise I would have ditched objects long ago. > -- > Matthew Woodward > [email protected] > http://www.mattwoodward.com/blog > > Please do not send me proprietary file formats such as Word, > PowerPoint, etc. as attachments. > http://www.gnu.org/philosophy/no-word-attachments.html > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to Mach-II for CFML list. 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/mach-ii-for-coldfusion?hl=en SVN: http://greatbiztoolsllc.svn.cvsdude.com/mach-ii/ Wiki / Documentation / Tickets: http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/ -~----------~----~----~----~------~----~------~--~---
