Ken Weiner wrote:
The issue I was getting at was that knowing that your app has this lazy
loading capability, you may make different design decisions on what
methods go into your domain objects and what your domain object graph
looks like. I prefer to design the domain object graphs, keeping in mind
that the DAO layer would be responsible for completely loading the
graphs. So if there are many Employees for a Company and you don't
always want to load the Employees when you load a Company, then I
probably wouldn't put a getEmployees() method on the Company class. I
guess you could argue that it is okay to add the getEmployees() method
and document it so that sometimes it returns null and sometimes it
doesn't, but that seems undesireable to me. I'd rather leave off the
method and add an extra method to a DAO that can fetch the employees for
a Company whenever I need them.
I agree you can run into the problem, but on the other hand, the
OpenSessionInView filter like it is implemented in Spring enforces
explicit transactions (which then can be bound via AOP) which is a plus...
But I agree, if you have the lazy loading constantly in mind you weave
your design decisions around it, therefore I prefer to shut off my mind
in that area....
But the problem is not really that big, because if you have to shift
objects from one page to the next you run into the lazy issues again
anyway, like the original poster did. I see lazy loading mainly as a big
helper for things like master pages which have to display a table which
goes over 3-4 objects per row and for a timesaver because you spend less
time on the mapping scheme adjusting it to some stuff lazy and some
stuff non lazy.
For the really hard parts the opensessioninview filter does not help at
all anyway.
In the end, given my experience, I assume it is not too different if you
use a lazyloading approach with an opensessioninview filter or if you
weave your designs around an explicitely loaded object tree.
The must thing however always is, use DAOs, and if possible business
objects with transactions woven around the accessor methods.
(A pattern which Springs OpenSessionInView filter enforces, due to the
flush mode it sets)
