Re: JSF + Spring + Hibernate

[Ken Weiner]

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.

-Ken

On 8/31/05, Werner Punz <[EMAIL PROTECTED]> wrote:

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
>>
>
>