Win a copy of Think Java: How to Think Like a Computer Scientist this week in the Java in General forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Best practice for view data population

 
Patrick Davenport
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1638
IntelliJ IDE Java MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Andy Hahn
Ranch Hand
Posts: 225
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 18152
52
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

 
Nitesh Kant
Bartender
Posts: 1638
IntelliJ IDE Java MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic