2

Intro
I'm the newest guy on my development team. We primarily do Java web development and work with Oracle databases, but on rare occasion we work with other RDMSs. In the interest of expanding my professional knowledge and exploring more modern methodologies, I decided to learn Hibernate.

So far, I'm unsure if its a good fit within our team - but I can't tell if that's because Hibernate legitimately does not suit our needs or because we follow such bad practices that Hibernate is "unwilling" to come along.

For example, virtually all of our interaction with the database is through standard JDBC CallableStatements and stored procedures. We iterate through ResultSets and place them into beans/pojos for the web app's use. Hibernate, from what I can tell, instead likes to exactly model tables (@Entity, @Table) and their columns. For simple SELECT queries, this is a mildly simpler approach. However, For elaborate DB work (think running analytics on the raw data), I'm either stuck with manipulating the data in my Java code heavily (and abandoning the entity-classes that map tables eventually) or calling stored procedures via an ugly session.doWork, which seems to defeat the entire point of using Hibernate to begin with.

Assumptions I have no clue about: My team told me early on that they think its better to do "heavy lifting" in the database (i.e. stored procedures) rather than in the app server (i.e. Java), and I have no idea if they're right or wrong. If they're right, then why do ORMs like Hibernate exist?

Also, I've heard that Hibernate has a pretty stiff learning curve, but I feel like I'm missing the point entirely. Are database tables supposed to exactly mimic the data you need in the web app? Is our design methodology that far gone?

Finally, I know stored procedures vs ORMs is a hot topic, but the trend seems to be on ORM's "side." Why?

tl;dr Hibernate appears to only help our use-case in the most trivial of cases, with a bunch of complicated configuration and extra resources as a trade-off. What am I missing?

Community
  • 1
  • 1
WannabeCoder
  • 498
  • 1
  • 5
  • 20
  • Please read @ http://stackoverflow.com/questions/448684/why-should-you-use-an-orm – Amogh Apr 30 '15 at 13:51
  • 2
    Hibernate is great for simple stuff. For harder stuff the object-relational impedance mismatch becomes an issue. RDBMSs are really good at doing RDBMS-type stuff. Java developers trends towards ORM because they're Java developers, not SQL developers. – Dave Newton Apr 30 '15 at 13:58
  • This question calls for an opinion-based answer, so I am voting to close it. The answer depends almost entirely on the team. It looks like you have some database_programmers™ on the team, which virtually guarantees some hostility toward the new ORM technology. Generally, this tends to be a lot more of a people issue than it is a technical issue. – Sergey Kalinichenko Apr 30 '15 at 13:59
  • @DaveNewton Your comment is perfect confirmation of my suspicions on Hibernate. When I first arrived here I learned a lot of SQL, so coming back to an ORM seems so... bad. – WannabeCoder Apr 30 '15 at 13:59
  • 1
    @dasblinkenlight That in itself is an answer. I'm looking for why my approach seems so misaligned. If it's "people have biases towards these technologies depending on their backgrounds" that's an answer in itself. "People have opinions" as an answer is *not* an "opinion-based answer." – WannabeCoder Apr 30 '15 at 14:01
  • 1
    The point is that you can argue either way, essentially indefinitely, based on people, technology, project, environment, etc. – Dave Newton Apr 30 '15 at 14:05
  • I'm currently converting all oracle stored procedures to java and hibernate for my client because they're tired of Oracle's pricing model and want to use another database. Stored procedures can be great in regard to performance but it comes with a tight coupling to Oracle. – crea1 May 04 '15 at 12:57

2 Answers2

1

Long story short, if you are questioning the use of Hibernate in your project, do not use it. Better design DAOs and DTOs correctly, so that routine operations will not take much effort to implement. Also, see Spring JDBC template its functionality may really help you.

P.S. If your team is not familiar with Hibernate, it will be much struggle to work with

lopushen
  • 1,117
  • 2
  • 11
  • 32
  • Thanks for the tip on Spring JDBC template. I'm already using Spring and I feel like this will fit in well. – WannabeCoder Apr 30 '15 at 14:09
  • But it will be a struggle -once-. Not being familiar with something is a really poor reason to avoid it completely, its the perfect reason to go investigate it. Let me put that differently: if you're unfamiliar with french fries I hope to god you at least go take a sniff so you may be tempted to have a taste too. If you don't even like the smell you can always keep eating raw potatoes. – Gimby Apr 30 '15 at 14:23
  • Not sure if I am currently understood. I did not state it as a reason to refuse using Hibernate, I've just put it as a note (that is why it is in P.S. ). Apparently, @WannabeCoder has more reasons to look for alternatives. – lopushen Apr 30 '15 at 14:37
0

I just share my experience. I'm working on a project with a clear separation between application layers; my team works on server side code, another team works on databases and another one configures and mantains application containers. In this scenario Hibernate (an ORM in general) allows us to be indipendent (i know, not completely) from database implementation details.

Another advantage, from my point of view (but this depends on the database structure), is the possibility, and I found this possibility very useful, to browse table relationships using Java and OO patterns. In this case please consider lazy loading.

Good Luck!

venusoft
  • 150
  • 13