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/blogPlease do not send me proprietary file formats such as Word, PowerPoint, etc. as attachments.
http://www.gnu.org/philosophy/no-word-attachments.html
smime.p7s
Description: S/MIME Cryptographic Signature
