Opinions on hibernate beans in JSP pages

[js]

Right now, I have Struts action classes doing the heavy lifting of
retrieving and saving objects into the database using hibernate.

These hibernate beans, plus the form object that is mapped to the action
class, are then available in the JSP page.

Question is, is it good practice to have hibernate beans on JSP pages ??
For example, in hibernate, a call such as:

<%= order.getClient().getName() %>

.... assuming using lazy loading, will cause a select on the client database
table to get the client's name for that order.

Is it bad practice to have that code in the JSP page ( because in the end,
it actually results in a database access in the JSP page ) ?

Is it better to actually to have that code in the struts action, and save
the name in an HttpRequest attribute ?, like so:

String clientName = order.getClient().getName();
httpRequest.setAttribute( "clientName", clientName );


<%= request.getAttribute( "clientName" ) %>


J

 

[dwi]

You should try to adhere with the MVC design philosophy. I don't think
it's a good idea
to mix business logic with presentation stuff together. Especially
worst is when you have
direct db access in your jsp.
One way is to create a view object that you pass all the data required
in the presentation,
then use this object in the jsp, eg.
view object
JSP <----------------> Action <---> model <---> DB (via hibernate)

That way you create a nice separation between your model and view
layer.

Cheers, DF.

 

[js]

You should try to adhere with the MVC design philosophy. I don't think
it's a good idea
to mix business logic with presentation stuff together. Especially
worst is when you have
direct db access in your jsp.
One way is to create a view object that you pass all the data required
in the presentation,
then use this object in the jsp, eg.
view object
JSP <----------------> Action <---> model <---> DB (via hibernate)

That way you create a nice separation between your model and view
layer.

Cheers, DF.

That's what I have in mind.

What makes this hard to detect is that, because Hibernate beans are just
ordinary beans, you don't immediately know that the bean will cause
database operations by Hibernate when calling the getter methods. So a JSP
developer may assume that the bean is actually a "view object".

Assuming for the moment that all the developers know which beans are
Hibernate ones, what is the best way to "transfer" the properties of the
Hibernate beans to the "view object" ? .... keeping in mind that getter
methods on the model bean may result in a select database operation
[ order.getClient() will cause Hibernate to retrieve all columns of a
specific row of the client table, where client is the client for that
order ] ?

Here's what I have in mind:

Create a view class with only the information you needed to have available
to the JSP page, and then populate the view object with data from the model
bean. This strategy ends up more tedious, as you have to code for copying
each property / attribute, but you avoid unnecessary database access
specially if you are using lazy loading with Hibernate.

The alternative is to:

a) Create a view class with the exact same attributes / properties of the
"model bean", thereby ending up with all the same method names for both
"model bean" and the "view object", and

b) Copy the same attributes / properties from the model to the "view
object" [ e.g. using Apache BeanUtils.copyProperties() ], am


In Action:

BeanUtils.copyProperties( orderView, order );

In JSP:

<%= orderView.getClient().getName() %>


However, step a) above causes a lot of unnecessary database select
operations, even if you use lazy loading with Hibernate, since you are
effectively copying all attribute.


Any additional thoughts ?

 

[Adam Maass]

Right now, I have Struts action classes doing the heavy lifting of
retrieving and saving objects into the database using hibernate.

These hibernate beans, plus the form object that is mapped to the action
class, are then available in the JSP page.

Question is, is it good practice to have hibernate beans on JSP pages ??
For example, in hibernate, a call such as:

<%= order.getClient().getName() %>

... assuming using lazy loading, will cause a select on the client
database
table to get the client's name for that order.

Is it bad practice to have that code in the JSP page ( because in the end,
it actually results in a database access in the JSP page ) ?

Is it better to actually to have that code in the struts action, and save
the name in an HttpRequest attribute ?, like so:

String clientName = order.getClient().getName();
httpRequest.setAttribute( "clientName", clientName );


<%= request.getAttribute( "clientName" ) %>

Hibernate seems to be designed for just such an approach -- if you want to
take it. The risk, of course, is that you may end up with "beans" that have
methods solely for presentation purposes, and your beans may expose methods
that don't have any business being exposed to the View.

Whether you're willing to tolerate that risk is up to you...

-- Adam Maass

 

[Chris Smith]

Question is, is it good practice to have hibernate beans on JSP pages ??

First, a little common terminology, which will help if you want to
Google for some of the common design holy wars that occur regarding this
topic.

When discussing design of multi-tier database-based applications, you'll
often end up having DAOs and/or DTOs. DAOs (data access objects) are
objects that encapsulate the logic of communicating with your database.
DTOs (data transfer objects) are objects that store data from the
database to be communicated to other layers of the system. DTOs do
*not* encapsulate a connection to the database. They contain data that
has already been retrieved from the database.

Now, whether it's a good design decision or not (and that's often up for
debate), Hibernate -- as distinct from most other O/R mapping options --
provides you with the intriguing possibility of using *exactly* the same
object for both a DAO and a DTO. That is, you can retrieve an object
from the database, ensure that all the necessary state is loaded, and
then disconnect it from the database to be used as a DTO. Accessing the
object's properties, then, will not cause a database access to occur.

Although the same object is used in both cases, it's important to keep a
handle on the difference between a connected object associated with an
open session, or a disconnected object that's isolated from the
database.

So there are essentially two questions you could be asking:

1. Is it good practice to use connected Hibernate objects from a JSP?
2. Is it good practice to use disconnected Hibernate objects from a JSP?

Here are my answers:

#1

It can be easy to do things this way (and avoid DTOs entirely) in small-
scale applications. If you need scalable performance, though, then no.
The problem is that you're tying database connection lifecycle to HTTP
connection lifecycle. Typically, your database connections are over a
fast local network, and the DBMS is optimized for a relatively small
number of simultaneous connections and heavy use of each. HTTP
connections are low-overhead, often high-latency, and dependent on all
kinds of stuff outside of your control. By tying the two together, you
get high-latency, unpredictable database connections that can cause you
serious problems. That's why you use DTOs in the first place.

#2

This is the considerably more appealing option. It avoid a lot of
duplication of effort to not need to write separate DTO classes, and you
avoid the disadvantages of #1. The (potential) problem is that you're
still exposing the entire data model at the presentation tier, and that
means that you lose some flexibility in the business tier. Whether that
matters in your architecture is a question that you won't find answered
reliably on USENET.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[js]

First, a little common terminology, which will help if you want to
Google for some of the common design holy wars that occur regarding this
topic.

When discussing design of multi-tier database-based applications, you'll
often end up having DAOs and/or DTOs.

.... snip ...

Yes, I am aware of that, but good to point out to others who may be reading
this thread.

So there are essentially two questions you could be asking:

1. Is it good practice to use connected Hibernate objects from a JSP?
2. Is it good practice to use disconnected Hibernate objects from a JSP?

Here are my answers:



#2

This is the considerably more appealing option. It avoid a lot of
duplication of effort to not need to write separate DTO classes, and you
avoid the disadvantages of #1. The (potential) problem is that you're
still exposing the entire data model at the presentation tier, and that
means that you lose some flexibility in the business tier. Whether that
matters in your architecture is a question that you won't find answered
reliably on USENET.

Option 2 is what I am currently doing. With lazy initialisation in
hibernate, I force the loading of the associations that I know will be used
in the presentation layer, and then close the Hibernate session.

I agree it avoids the duplication of DAO and DTO, and hence, Hibernate
beans / POJO are just too tempting.

Never mind my architecture ... what have others done ?