OpenSessionInViewFilter recently, access, filter, where

amy

Hi all,

Although I see the advantages of using this filter to access data (from the database) I'd like to know if this really is good practise. I recently worked on a project where the developers where using this and pushing (hibernate) beans out into the (JSF) templates. By accessing the different public methods available one was able to pick up data from the database, albeit via the proxy. Exceptions relating to data not found etc are shown directly to the client.

My question is if this is not just like opening a jdbc connection from a jsp, just a little more abstract :-)
Is it not better to limit this to the services layer and return required domain objects to the web layer?

Thoughts?

/Colin

Your question is very similar to a discussion in the following thread:

showthread.php?t=19488

I would agree with you - using domain objects at the web tier layer is not a good practice.  The domain object being returned from the persistence layer should be converted into standard POJO's in the service layer.  The standard POJO's should then be returned to the web tier layer for displaying data.

This approach should also be used when saving data from the web tier (i.e., service layer receives the POJO, converts it into a domain object, then passes the domain object to the persistence layer).

This approach buys you several things:

1.  More decouplization between layers

2.  Allows you to open your service layer methods up to Web Services, without exposing your domain model to the consumers of your Web Services (your method at the service layer only takes a POJO, not the domain model)

3.  Allows for greater flexibility when using Spring MVC (i.e., simply use your standard POJO's as the command object and the form backing object - yes, you could use your domain model as the command object, however, you'd potentially introduce domain model specific code to your web layer that you'd otherwise not necessarily want there)

4.  If you're using Hibernate, you don't have to worry about using the OpenSessionInFilter/Interceptor, or worry about inadvertently saving values to the database, even if validation errors occur (yes, this does happen - in edit mode of a form, if you're using the domain object as the form backing object, you click save and validation errors occur, values will still be committed to the database – yes, there are work-arounds to this like setting setAlwaysUseNewSession to false, but this approach may present performance impacts.

Just my experience and two cents...

I would disagree with you

I think the overhead of maintaining two quot;modelsquot; which represent your domain model (i.e. the domain model itself and a graph of VO you send to your web tier) is way over complicating things   If your web tier is graphically manipulating your domain model, why duplicate it.

Sure, if your web tier/consumers are expecting different domain models then introducing a conversion layer is required, but that is a pretty specialised case.

Just my thoughts

P.S.  My solution to hibernate backed POJOs are to simply rollback if there are validation errors.

I'm with matthewramella on this one. Since a Hibernate entity is effectively a quot;livequot; database connection it always seemed dangerous to me.

For me, the beans that are displayed to the user and submitted in forms are separate from the Hibernate entities.

I know that this means there is a lot of property swapping going on, but I just feel safer doing it like that. Besides, if you use Commons BeanUtils to do the copying, at least some of the pain is taken away.

Bob