Hibernate and resource utilization

I was ha开发者_开发知识库ving a discussion at our office whether to use Hibernate or not. Currently our code uses pure jdbc and sql statements in order to get the data we need. As you can imagine this makes our code hard to maintain. I suggested to switch to Hibernate to make our code look and work better. However, our application needs to have high performance (in terms of time and memory utilization). My colleagues kept arguing that switching to Hibernate would make us fetching unnecessary data, so making our application slower and consuming more RAM memory.

Is it really true? Are there any tricks we could use? Are there any arguments I could use in the discussion with my colleagues?

Thanks!

---

First of all, for most applications there is a tradeoff between high performance and low memory. If you want both, you usually have to consider other tradeoffs, e.g. maintainability like in your application with JDBC.

You can argue to your colleagues, that for all relationships the fetch type can be specified:

• EAGER - fetch the field when the bean is loaded
• LAZY - fetch the field only when the field is used

This takes place when the bean is under control of the entity manager. If you remotely fetch objects, additional LAZY loading is not possible. But the question, if Hibernate is a solution for your requirements depends much on the nature of your application.

If have a web application and huge object graphs it is a great benefit if you are using JPA/Hibernate and e.g. something like SEAM, thus having all objects under entity manager control (even in your JSF managed beans). There you don't have to care about what fields in your object graph are actually required and therefore don't need to spent any single line of code in this question.

But if you undertake e.g. scientific or financial calculations, it's of course faster do get everything you want by customized (and large,complex and hard to maintain) SQL statements. For my developments I use JPA (and in the backend Hibernate) if possible. The cleaner code is more important for us than some microseconds of faster computation time.