Win a copy of Think Java: How to Think Like a Computer Scientist this week in the Java in General forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

is hibernate the road to walk

 
ing erl
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi!

Doing this tiny desktop application, connection to a database with eight
up to ten tables in it.
using matisse in netbeans 5 and using the derby database from apache,
deploying it all in one package ... wanting to keep it that way.

today, the code I use when writing object to my db is quite ugly,
Strings of SQl are stored in one class ... and I am forced to do some
tweaking. Not using views nor stored procedures yet in the db.

is JDO the right path for me to go, simple enough for this project ?
or should I go the hibernate way, or is the learning curve to steep here ?

could you give me some advice here, would like to do this in a
simple yet a nice way ...

best regards, i
 
Chris Richardson
author
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

A good first step might be to use iBATIS to simplify your code and move the SQL into external files.

JDO and Hibernate are roughly equivalent in terms of learning curve...

Chris
 
Jeff Albertson
Ranch Hand
Posts: 1780
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If JSO and Hibernate have roughly equivalent learning curves, how about iBATIS's? If learning Hiberate is like learning to ride a bicycle w/o training wheels, iBATIS is learning to:
1) ride a bicycle with training wheels
2) ride a tricycle
3) use of of those push toys that make colored balls bounce around.

 
Gerardo Tasistro
Ranch Hand
Posts: 362
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by ing erl:
Hi!

Doing this tiny desktop application, connection to a database with eight
up to ten tables in it.


If it is small and wont grow or app size is an issue (as in JAR size). Keep JDBC. Otherwise Hibernate is a good option. Gives you a lot of flexibility and you really focus on the code and not the data retrieval as all queries are object based.
 
Pj Murray
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Gerardo Tasistro:


If it is small and wont grow or app size is an issue (as in JAR size). Keep JDBC. Otherwise Hibernate is a good option. Gives you a lot of flexibility and you really focus on the code and not the data retrieval as all queries are object based.


Unless of course, your application has serious performance requirements, in which case Hibernate is an extra layer of code on top of JDBC.

If the architecture is service-oriented, you should use SDO (service data objects).


You should use Hibernate if you don't know JDBC, you're in a rush, you don't have special performance requirements, you're not using SOA/Web Services, etc....



I guess what we're trying to say here is that it all depends on your specific requirements, there's one 'one size fits all' answer.
 
Sabarish Sasidharan
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Chris Richardson:
Hello,

A good first step might be to use iBATIS to simplify your code and move the SQL into external files.

JDO and Hibernate are roughly equivalent in terms of learning curve...

Chris


I too second the choice of iBATIS. I have never used iBATIS but have used a custom framework that very much resembles that. I have been using Hibernate for around 2 yrs now. And i know there are many ways of getting lost when using Hibernate.
 
Jeff Albertson
Ranch Hand
Posts: 1780
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by PJ Murray:

Unless of course, your application has serious performance requirements, in which case Hibernate is an extra layer of code on top of JDBC.


But then Hibernate may *speed* up your application because of its caching, the SQL code it uses which may be tuned to you DBMS, the 80/20 rule (let it write the 80% of the database access where performance isn't an issue so you focus your time and attention on the critical 20%) ...
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic