well OpenSessionInView... is one of those rare circumstances where it
actually makes sense, because it eases the portability and implementation...
I would not say it reall is dependend on the view layer, more on the
control layer of the server...
It is one of those border cases...
Larry Meadors wrote:
Heheh, are you suggesting that making your DAO layer depend upon your
view layer is a bad idea?
I would have to agree....
Larry
On 8/31/05, Ken Weiner <[EMAIL PROTECTED]> 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
