Actually some valid points here, but the whole
opensessioninviewfilter technique is more like
a keep the session open as long as possible technique, so
that you do not have to care about it anywhere.
so basically what happens is following, that
normally you have the problem of keeping track of prefetching etc...
and often the session handling on dao level,
now the session handling is moved into the request cycle and now should
be fully transparent to the user (not allways but often enough)
the benefit you get from this, is that you do not run into the lazy
loading issues as often as with small dedicated sessions...
So what happens if you move lets say from Hibernate to plain JDBC...
you simple remove the opensessioninview filter
and from the outside you handle the pojos the same, all which happens is
that you replace lots of lazy loaded classes and some dao code with
the same classes prefilled from the jdbc connection...
the OpenSessionInView filter basically just eases the pain of having to
keep track of lazily loaded classes in many instances (not in all)
but besides that is rather transparent to the implementation if done well...
I wil give you an example....
without OpenSessionInView...
load some person classes
getHibernateTemplate().load(Person.class, id);
with OpenSessionInView
getHibernateTemplate().load(Person.class, id);
the main difference is, that if person in the first case references
another bunch of lazy objects
like:
person.getAddress().getStreetName()...
you might get an error while rendering the data or doing something with it
in the second case you wont get the error, because the lazy loading
still can be done due to the open session.
ideal would be to have some kind of session per session filter
but in most circumstances that is not possible, so opensessioninview
is the second best choice you can get.
Werner
Ken Weiner wrote:
I have a question about designing a webapp to use a DAO layer, lazily
loaded objects, Hibernate, and the OpenSessionInView technique.
Doesn't this strategy make it very difficult to reimplement the DAO
layer sometime in the future? If you switched a DAO implementation from
Hibernate to let's say, Spring JDBC, then how would all the lazy loading
work? There would be no equivalent OpenSessionInView technique for
Spring JDBC. For this reason, I have been shying away from designing my
domain objects such that the rest of the app expects them to lazily load
data.
So, instead of a Company class having a getEmployees() method, I would
choose, instead, to have a CompanyDao.getEmployees(Company company)
method that must be called at the point my webapp needs all the
Employees for a Company.
Have any of you had the same concerns? Or am I missing how a webapp
that relies on lazy-loaded object graphs can change DAO implementations
easily?
-Ken
