This week's book giveaway is in the Java 8 forum.
We're giving away four copies of Java 8 in Action and have Raoul-Gabriel Urma, Mario Fusco, and Alan Mycroft on-line!
See this thread for details.
The moose likes Performance and the fly likes Best practice for view data population Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » Performance
Bookmark "Best practice for view data population" Watch "Best practice for view data population" New topic
Author

Best practice for view data population

Patrick Davenport
Greenhorn

Joined: May 12, 2009
Posts: 10
I've been working on a .NET application and experiencing a memory error (I'm a java developer that can do other things), I've been thinking about performance. What I'm posting about was not the memory problem. The memory problem just started me thinking.

I've repeated a trend in my ASP.NET application that I've used on countless J2EE applications: using Business Entities to populate drop down lists. The more I think about it, the more I don't like it. For example, on the app I'm working we have a drop down list of current projects. A project is a graph of objects. However, to create the list we pull back all of the projects, create the graph and only use the id and display name. This seems to be a terrible waste. To be fair, the dal layer is entirely hand written. The lead architect would not allow an ORM like NHibernate.

I realize that all of these objects are in GEN0 and quickly garbage collected. What worries me is that I'm taxing the GC. Ever 5% of the CPU needed to process the GC is 5% of CPU I can't use else where. This site is one of the few that I really respect. What do you all think? Is it bad to use the entity model for this? Should I create a set of IdValue objects that only house the display value and id? Would creating such a view object tier (I don't suppose this will go in the business layer) just create redundant code?

Thanks,
JPD
Nitesh Kant
Bartender

Joined: Feb 25, 2007
Posts: 1638

Patrick Davenport wrote:Should I create a set of IdValue objects that only house the display value and id? Would creating such a view object tier (I don't suppose this will go in the business layer) just create redundant code?


If i were to write it, i would modify the business layer to optionally take field names that needs to be queried from the DB for a particular operation. In this way people can get the same DAO with the fields of their choice populated in it.
If somebody does not need this customization, the he/she can call the default method with no field names.

eg: If i have to query employee information from the DB, I can have a single Employee bean:



and i can have the business layer as;



This will make the code reside in the business layer and hence can be reused by the view layer as well as other business layer classes.


apigee, a better way to API!
Andy Hahn
Ranch Hand

Joined: Aug 31, 2004
Posts: 225
Exactly. I never return business objects directly to my JSP. I always use a view bean class but that's just me. Other people that like Hibernate more than they should use things like OpenSessionInView filter but I dont agree with that pattern. Also, I don't know that I would worry so much about GC and processor performance. You should monitor your peak CPU and as long as you re under 90% then youre good. If you start approaching 100% then you will want to tune your configuration.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15662
    
  15

Andy Hahn wrote:Exactly. I never return business objects directly to my JSP. I always use a view bean class but that's just me. Other people that like Hibernate more than they should use things like OpenSessionInView filter but I dont agree with that pattern. Also, I don't know that I would worry so much about GC and processor performance. You should monitor your peak CPU and as long as you re under 90% then youre good. If you start approaching 100% then you will want to tune your configuration.


Good practice is to keep the database abstracted from the business logic. It keeps the persistence implementation details from leaking up into the higher levels and it gives you the freedom to tune the database structure without trauma to the application.

Nitesh's per-field request idea sounds attractive until you realize that that's basically what JDBC does, which is pretty much the opposite of the previous paragraph.

Oh, and generally you want to start tuning at an 80% workload. That last 10% tends to evaporate quickly during spikes, although YMMV. Business may like to talk about "giving 110%", but once a computer system hits 100%, it typically starts avalanching. IT is like war. It's always good to keep something in reserve. Too much efficiency can become very inefficient.

If databases can have Views, I don't see any reason why persistence mechanisms can't - just try and keep them read-only unless you want the extra headache that comes with trying to remember what stuff reflects modifications to other stuff.

But you really need to get your architect to advance into the Third Millenium. ORM not only makes the job easier, benchmarks typically show a 2-to-1 performance boost over raw JDBC for enterprise-complex loads, and you can forget about worrying regarding GC, since the ORM caching handles things.

I don't however, use OpenSessionInView myself. It makes things a little more complicated, but so far I've managed to keep things under control by limiting my working set and adding limited eager fetches and explicit load request methods to the DAO for the side items.


Customer surveys are for companies who didn't pay proper attention to begin with.
Nitesh Kant
Bartender

Joined: Feb 25, 2007
Posts: 1638

Tim wrote:Nitesh's per-field request idea sounds attractive until you realize that that's basically what JDBC does, which is pretty much the opposite of the previous paragraph.


I agree that if we have DB column names as field names, we will have a tight coupling between the DB table structure and the Business logic. However, if the field names refer to bean field names then we can get rid of that coupling.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Best practice for view data population
 
Similar Threads
implementation strategy for a simple ordering application.
S2: Action/DAO mess...
Garbage collection with CMP Entity beans
Working with complex detached object graphs in EJB3 or hibernate in 3-tier architecture
static method or non-static method?