Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

designing hibernate apps

 
Glenn Timchishen
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was wondering if anyone knows any sites/pdfs/tutorals on incorporating hibernate into the design of a application.

Not worried about code syntax and details, but more so on working hibernate into the class diagrams. Do I have to put hibernate into seperate classes or can I incorporate hibnerate logic into the regular business POJOs?


Thanks!
 
Pierre Henry
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, ,

You can reuse your POJOs, with minor modification, into a model layer, and map them with hibernate mapping dtd.

It depends then, if you have already a schema or not. But in all cases , you will have a model/persistance/service layers architecture for the data part. Then for the view another layer (jsp/jsf/ajax).
 
Glenn Timchishen
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well I was thinking about...

I have my Pojos lets say user. A javabean that has all the user info, username/password, address, city, etc.

Then I have an userManager class this class will have all of the business logic attached to adding/updating/deleting users.

So then I was thinking of having all of my hibernate session code in a class by itself and then having all of the "Manager" classes implement an interface which would force the implementing class to include an instance of the hibernate helper class. The hibernate helper class would get inited by Spring's indepency injection.

Now i'm thinking this is a good design, but when ever I look at any book regarding designing a spring/hibernate app it has DAO for ever pojo javabean class.

So am i missing something? Doesn't that seam like your having alot of extra code?
 
Tim Holloway
Saloon Keeper
Posts: 18366
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You don't need a DAO for every persistent POJO, just the ones that you need to be able to fetch or update directly. After that you can chase through the related objects - which is where the 'R' in ORM comes in.

There's a lot to be said for using the same POJOs as both business objects and as persisted objects, but some frameworks handle that better than others. For the frameworks/cases where you can't go that route, you have to fall back to doing data transfers.

In case you're interested in data transfers without having to do all the work yourself, there's a project called "dozer" on the sourceforge that can use introspection and other bits of cleverness to reduce the grunt work.
 
Pierre Henry
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Glenn,

Having a DAO for each POJO is a good design. Why ?

Becaus when a request is made at the presentation level that requires to get a POJO, Spring gives a handle to the specific DAO required for that session to take place in a separate thread.

And that is good for load balancing, because you just rely on the container to do that and match perfectly the perstance/model/service/view layer model.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic