Why ORM with hibernate ?
posted 9 years ago
I wanted to throw this question out for a while and it appears that Cameron is promoting his book as well. Cool coincidence 
I was discussing using Hibernate with a co worker. He had used it on his previous project. I asked him about the performance overhead and he said hibernate was slower. Then I assumed it took him less time to code with hibernate and he said the opposite was true.
Now, some one that uses DAOs to access the DB will enjoy a lot of flexibility. I am not sure how flexible hibernate can be. How does it handle complex types, BLOBs etc and what about performance gains or reduced coding times. I have never felt compelled to use hibernate.
Does anyone here have metrics to prove hibernate reduces your time or increases performance. I appreciate that everything would become object oriented and you dont have to write sql handling code but that has never been a convincing argument for me.
Oh and Cameron... does your book say anything about performance, advantages etc of using this framework ? Or is this book aimed at people who know that they want to use hibernate and its a quick and easy way for them to get started ?
Good luck on your journey writing books and I hope you have success with it.
I was discussing using Hibernate with a co worker. He had used it on his previous project. I asked him about the performance overhead and he said hibernate was slower. Then I assumed it took him less time to code with hibernate and he said the opposite was true.
Now, some one that uses DAOs to access the DB will enjoy a lot of flexibility. I am not sure how flexible hibernate can be. How does it handle complex types, BLOBs etc and what about performance gains or reduced coding times. I have never felt compelled to use hibernate.
Does anyone here have metrics to prove hibernate reduces your time or increases performance. I appreciate that everything would become object oriented and you dont have to write sql handling code but that has never been a convincing argument for me.
Oh and Cameron... does your book say anything about performance, advantages etc of using this framework ? Or is this book aimed at people who know that they want to use hibernate and its a quick and easy way for them to get started ?
Good luck on your journey writing books and I hope you have success with it.
posted 9 years ago
It's funny, but right off the bat in prologue of the book, I talk about how much I hate preambles. I then go on to say how I always feel compelled to read them, but in the end, they are little more than marketing hype, sales, and stuff like that. I mean, if someone bought the book Hibernate Made Easy, do I really need to tell them why it's so great? If they're reading the book, they need to learn Hibernate, regardless of whether it's good or bad. And for that matter, if I can help them learn Hibernate, they can decide for themselves, and make their own decisions - they don't need my amateur opinion influencing theirs, right?
Anyways, I go on about how much I hate long preambles, until I've got a preamble that itself is unbearably long. Ironic, isn't it?
Hibernate marshals all of its calls into JDBC SQL code, so, in the end, a SQL call using Hibernate is not different that a SQL call that doesn't use Hibernate. The difference is, a good Java developer can focus on being a good Java developer, and any other good Java developer can maintain that code that was written by that Java developer. Few SQL or database skills are required.
Sure, you can always find an MIT grad to write crazy SQL queries that run in a millionth of the time that a Hibernate SQL call might take. But what happens when she goes away, and you now need someone to manage her crazy SQL code? You're in alot of trouble!
The cost of any application is not how much it costs to get it deployed, or how much money an extra bit of RAM will cost. The cost of any application is its long term maintenance and management. That's where you get hit.
With popular frameworks like Hibernate, you'll find training new people, and maintaining existing code becomes much easier. That's a huge benefit.
The key is always using the right technology for the job. Many people have found that Hibernate is the best resource for their particular problem domain, and that is why it keeps gaining in popularity. It's certainly not a one-size-fits-all, and when people don't understand how Hibernate works, they often do things that slows it down or creates too many queries, or causes inefficient database interactions. However, in my experience, when people really understand how Hibernate works, and how it should be used, they love it, and they end up using it in all typse of situations.
-Cameron McKenzie
I then go on to say how I always feel compelled to read them, but in the end, they are little more than marketing hype, sales, and stuff like that. I mean, if someone bought the book Hibernate Made Easy, do I really need to tell them why it's so great? If they're reading the book, they need to learn Hibernate, regardless of whether it's good or bad. And for that matter, if I can help them learn Hibernate, they can decide for themselves, and make their own decisions - they don't need my amateur opinion influencing theirs, right?Anyways, I go on about how much I hate long preambles, until I've got a preamble that itself is unbearably long. Ironic, isn't it?
Hibernate marshals all of its calls into JDBC SQL code, so, in the end, a SQL call using Hibernate is not different that a SQL call that doesn't use Hibernate. The difference is, a good Java developer can focus on being a good Java developer, and any other good Java developer can maintain that code that was written by that Java developer. Few SQL or database skills are required.
Sure, you can always find an MIT grad to write crazy SQL queries that run in a millionth of the time that a Hibernate SQL call might take. But what happens when she goes away, and you now need someone to manage her crazy SQL code? You're in alot of trouble!
The cost of any application is not how much it costs to get it deployed, or how much money an extra bit of RAM will cost. The cost of any application is its long term maintenance and management. That's where you get hit.
With popular frameworks like Hibernate, you'll find training new people, and maintaining existing code becomes much easier. That's a huge benefit.
The key is always using the right technology for the job. Many people have found that Hibernate is the best resource for their particular problem domain, and that is why it keeps gaining in popularity. It's certainly not a one-size-fits-all, and when people don't understand how Hibernate works, they often do things that slows it down or creates too many queries, or causes inefficient database interactions. However, in my experience, when people really understand how Hibernate works, and how it should be used, they love it, and they end up using it in all typse of situations.
-Cameron McKenzie
posted 9 years ago
Where I work, we support seven databases types. We swap from one to the other with a one line configuration change, and we only have one set of DAO implementation classes for all these databases. This is compared a legacy application we have, where the last change we had to support a new database took three developers four months to implement.
Hibenrate have their own performance FAQs which might give you some answers.
[ June 06, 2008: Message edited by: Paul Sturrock ]
[ June 06, 2008: Message edited by: Paul Sturrock ]
Hibenrate have their own performance FAQs which might give you some answers.
[ June 06, 2008: Message edited by: Paul Sturrock ]
[ June 06, 2008: Message edited by: Paul Sturrock ]
posted 9 years ago
Why do you swap from one to the other
. I guess you are trying to move from one DB to another ? I have to agree with your point that switching to another DB would be easier with hibernate. 7 databases ! I wonder how that happened. But then again I have seen weirder
A good point also. I have seen projects recommending hibernate without knowing fully how to go about using it.
Thanks for your replies
Where I work, we support seven databases types. We swap from one to the other with a one line configuration change, and we only have one set of DAO implementation classes for all these databases.
Why do you swap from one to the other
. I guess you are trying to move from one DB to another ? I have to agree with your point that switching to another DB would be easier with hibernate. 7 databases ! I wonder how that happened. But then again I have seen weirderwhen people don't understand how Hibernate works, they often do things that slows it down or creates too many queries, or causes inefficient database interactions.
A good point also. I have seen projects recommending hibernate without knowing fully how to go about using it.
Thanks for your replies
posted 9 years ago
Because a set of our applications are supported on seven databases. Its up to customers to choose which one they will use, not us. How it happens? A customer comes along saying "we want to buy your app, but we see it only runs with Oracle and we only use DB2 390" and someone extends the app. Before we implemented a DAO layer in Hibernate this was a long and very painful process.
A great argument for ORMs I think. Thankfully, the legacy app. is written in a technology I don't know so its not me that has to wrestle with it. So by all means apply to my company now - though I wouldn't be recommending it had you asked eight years ago!
[ June 06, 2008: Message edited by: Paul Sturrock ]
Why do you swap from one to the other
Because a set of our applications are supported on seven databases. Its up to customers to choose which one they will use, not us. How it happens? A customer comes along saying "we want to buy your app, but we see it only runs with Oracle and we only use DB2 390" and someone extends the app. Before we implemented a DAO layer in Hibernate this was a long and very painful process.
Paul, are you saying this is a good argument for Hibernate, that this is a bad argument for Hibernate, or are you simply warning us that nobody should send their resume to the place at which you work?
A great argument for ORMs I think. Thankfully, the legacy app. is written in a technology I don't know so its not me that has to wrestle with it. So by all means apply to my company now - though I wouldn't be recommending it had you asked eight years ago!
[ June 06, 2008: Message edited by: Paul Sturrock ]
