Why VOs (transfer objects) are good...but they can be abused like...

any other design pattern....

Sorry for the confusing title, but long titles are rather lame. So you're a flex cf, java, or php developer and you are leveraging all the beautiful one to one mapping associated with server and client object creation.

"YES!", you said. No more guess work; my server vals returned can be readily passed around within my AS code with the ease of code insight! Ctrl-space... wow theres my property! Ok, getting tacky I know.

So we embark on our design of a sytem always using VOs no matter the cost. Eee gaadd stop now. VOs, pending on design approaches may possibly have multiple layers of nested VOs YIKES!

Everyone knows that Rambo's weapons of choice were the bone cutting hunting knife and explosive bow and arrows. But there were times when he had to pull in the heavy artillery or perform a sneak attack with a much more lightweight approach like a choke hold (ahh, the violence of my youth...).

This is why VOs can be a problem if implemented without understanding the performance ramifications that can be incurred if they are always used.

Here's a real world scenario. Requesting an array of 100+ VOs from your middle tier that each have nested arrays of child VOs. Imagine just having two child VOs and the impact that could have on performance with this approach.

You call in to pull back the parent VOs that contain an array of child VOs (say 5) that all need to get created for each item in the array. So in this process we are creating 100 parent objects and internal to each we are creating 10 child VOs. This yields 1000 objects which each need to get created and the memory and process grow each time you do so on your middle tier (now add just a few users doing this incrementally over the first couple of hours).

I'm being facetious here of course as this isn't a very high number. But why return such a dense object to the client unless you were going to use it. There is a lot of wasted horsepower with this approach. Think of the scene with Rambo emptying that M60 E4 machine gun and never hitting his target... Rambo

A better approach is to pass back a snapshot of the data directly from your middle tier and pull back its VO representation when an edit needs to be performed or the VO truly is required to facilitate a process in the application.

So if you are going to populate a grid, I don't recommend doing it with VOs and if you absolutely have to create an array of VOs understand the possible performance impact (and data stagnation) that can ensue if the VO is of a complex nature and how it can impact the health of your server and ultimately the user experience.

The J2EE Core Pattern docs on Transfer Object speak to this. Check out the "Consequences" section of caching large sets of VOs. Line from the article: There is a trade-off associated with this strategy. Its power and flexibility must be weighed against the performance overhead... THE LINK

Comments (Comment Moderation is enabled. Your comment will not appear until approved.)
This is why tools like Hibernate added support for Lazy Loading (as the default). So if you use the right tool you can have your cake and eat it too (complext VO's).
# Posted By Mike Nimer | 11/30/07 12:49 PM
Hibernate is great when your UI layer is java based. You have your hibernate session open while you render your page allowing each child object to get loaded only when you want to render it. The problem is, how do you do that from a flex front end? When your actionscrip calls foo.bar.somethingElse, unless you initialized that lazy association, you won't have it in your object on the client.
# Posted By Rob McKeown | 11/30/07 5:20 PM
There is a way from flex, actually 2 but the 1st is still in secret stealth mode. As for the 2nd, If you use the Hibernate Adapter with Flex LCDS server and Data Management (not flash remoting) the hibernate lazy loading is supported. However a warning, the setup is tricky. But once you get it working it does work.
# Posted By Mike Nimer | 11/30/07 5:26 PM
Jeff,
RE> This yields 1000 objects which each ...
Actually it is 1100 objects... which contains 1000 child objects. :-)
# Posted By Thomas Burleson | 12/6/07 11:13 PM

Copyright Strikefish, Inc., 2005. All rights reserved.