7

Correct me if this is an exact duplicate, I know this topic is discussed often but can't find a definitive answer.

The question:

What is the best practical solution to handling Hibernate objects in a MVC webapp?

The details:

I am using Hibernate and want to leverage lazy loading where possible.
I am working in a MVC style webapp.
I hate getting lazy load initialization exceptions.
I hate having to reattach Hibernate objects between transactions.

The options:

  1. Eager load everything
    • Solves the lazy initialization problem but makes my queries bigger
  2. Use some 'Open Session in View' concept
    • I love the simplicity of it
    • Objects still need to be reattached, and in an AJAXy setup, quite frequently
    • A session is opened for EVERY request
  3. 'touch' items I need before leaving the transaction
    • Seems flimsy at best.. and tedious
  4. Create different, simplified, 'detached' objects so the view never sees real Hibernate objects
    • These could be simpler than full Hibernate objects so it's not like a full eager load of the model
    • I've heard this recommended in places to but just seems like more liability/code/work
  5. Open a session when ever I want to interact with Hibernate objects.
    • This can be wrapped up in a Spring Service layer pretty nicely, but seems excessive at times. Eg: I want hibernateObject.getRelatedObjects() but need to say something like springService.getRelatedObjects(hibernateObject)

Am I missing something?
Have I over-thought things?
Have I under-thought things?

PS:

For a web framework I'm using ZK but don't really want a ZK specific answer.
I'm also using Spring and am cool with a Spring specific answer as it's so ubiquitous.

Sean Connolly
  • 5,444
  • 7
  • 33
  • 67

3 Answers3

5

Use 4-ish - Don't use open session in view, don't have your hibernate entities bubble all the way up to the view instead have transformers translate between the hibernate entities and your domain objects or 'view beans' depending on how you want to work it.

I think of Hibernate entities as just a persistence strategy not a domain model or UI representation.

blank
  • 17,064
  • 19
  • 94
  • 151
  • Cheers Bedwyr, I think I'll take this approach. It's a bit more code but the separation of view and model should be worth it. – Sean Connolly Jan 18 '13 at 13:43
  • I agree with this answer and upvoted it, just want to add a piece of code you might find handy. Here is a variable depth copier, it depends on Spring but is lighter weight than a full mapping solution like Dozer. https://gist.github.com/thinkbigthings/5488327 – Jay Apr 30 '13 at 12:13
  • Also here is a Hibernate unproxifier: https://gist.github.com/thinkbigthings/5141813 – Jay Apr 30 '13 at 12:13
  • Isn't option 4 DTO pattern aka anti-pattern ? http://stackoverflow.com/a/1440994/2103767 – bhantol Sep 22 '14 at 20:26
3

There are three ways:

Use eager fetch load for your attributes: Can be a problem if you have a big datatable.

Use a filter called OpenSessionInView: this filter will keep the session open until the full load of your web page. If any hibernate object was request in this load, the session will be opened and will avoid lazy loading exception.

User VOs (Valueble Objects): In your application, will have 2 kinds of objects. A object to pass between the persistence and business layer, and a object for you view layer. For example, UserVO and UserModel. A vo will be used to transport information between view and business layer. In your business implementation, you will use the vo to fill the model object to send it to you persistence layer. Using this pattern, you wont have more lazy load exception because all needed information will be filled in your vo object when is necessary.

Some references:
OpenSessionInView
Eager Fetching Load
Hibernate Performance tips

Marcio Barroso
  • 753
  • 1
  • 6
  • 21
1

Mixing the Presentation layer with the Data Access layer is a design issue.

Your View should access the Model through a Controller, but by using Hibernate objects directly you're mixing layers. IMO Data Access should be another layer below the Model. Even if your entities are annotated or defined in an xml they're separate from the model per se.

Introduce a Facade or a Manager that encapsulates the Hibernate logic and expose it through a service contract for the controllers, returning meaningful objects that represent those entities. If any, I'd go for option 4.

Fritz
  • 9,677
  • 4
  • 26
  • 48
  • Thanks Gamb. It's a bit more code & work, but I think it'll make for a cleaner, more testable application. If I could accept both yours and @Bedwyr's I would - chose one randomly. – Sean Connolly Jan 18 '13 at 13:42
  • @SeanConnolly No worries, glad to be of help :) – Fritz Jan 18 '13 at 13:47