hibernate workflow

Question

Hi

I'm trying to write a program with Hibernate. My domain is now complete and I'm writing the database.

I got confused about what to do. Should I

• make my sql tables in classes and let the Hibernate make them
• Or create tables in the database and reverse engineer it and let the hibernate make my classes?

I heard the first option one from someone and read the second option on the Netbeans site.

Does any one know which approach is correct?

Answer 1

It depends on how you best conceptualize the program you are writing. When I am designing my system I usually think in terms of entities and their relationships to eachother, so for me, I start with my business objects, then write my hibernate mappings and let hibernate create the database.

Other people are able to think better in terms of database tables, in whcih case that approach is best for them. So you gotta decide which one works for you based on your experience.

Answer 2

I believe you can do either, so it's down to preference.

Personally, I write the lot by hand. While Hibernate does a reasonable job of creating a database for you it doesn't do it as well as I can do myself. I'd assume the same goes for the Java classes it produces although I've never used that feature.

With regards to the generated classes (if you went the class generation route) I'm betting every field has a getter/setter whether fields should be read only or not (did somebody say thread safety and mutability) and that you can't add behavior because it gets overridden if you regenerate the classes.

Answer 3

Definitely write the java objects and then add the persistence and let hibernate generate the tables.

If you go the other way you lose the benefit of OOD and all that good stuff.

Answer 4

I'm in favor of writing Java first. It can be a personal preference though.

If you analyse your domain, you will probably find that they are some duplication.

• For example, the audit columns (user creator and editor, time created and edited) are often common to most tables.
• The id is often a common field.

Look at your domain to see your duplication.

The duplication is an opportunity to reuse. You could use inheritance, or composition. Advantages :

• less time : You will have much less things to write,
• logical : the same logical field would be written once (that would be other be many similar fields)
• reuse : in the client code for your entities, you could write reusable code. For example, if all your entities have the same id field called ident because of their superclass, a client code could make the generic call object.getIdent() without having to find out the exact class of the object, so it will be more reusable.