12

We have an application thats already running for a long time. Now we are migrating it to Spring and possibly using Hibernate or any other ORM.

But we caught up with a question. Is it not recommended / bad idea to use Hibernate for the already existing Database and model the object around Schema?

Most people advocate NOT using Hibernate and instead of go with some other ORMs like iBatis. But in our company, all are proponents of Hibernate.

Any experiences?

Kevin Rave
  • 13,876
  • 35
  • 109
  • 173

4 Answers4

14

I would say that it's irresponsible to choose Hibernate, iBatis, or anything else without knowing your requirements.

If you don't have a solid object model, I'd say that Hibernate is a terrible choice.

If you use stored procedures as the interface to your database, I'd say that Hibernate is a terrible choice.

If you don't like the dynamic SQL that Hibernate generates for you, I'd say that Hibernate is a terrible choice.

Get it? Knee-jerk reactions like the ones from those Hibernate proponents aren't a good idea.

It might be that iBatis or Spring JDBC template is a better choice than Hibernate. You ought to become more informed about that decision and make it for your application rather than blindly listen to a mob.

You don't have to be all or none about it, either. It's possible to implement part of your solution with one technology and the rest in another.

I'd recommend making your persistence layer interface-based so you can swap implementations without affecting clients.

duffymo
  • 305,152
  • 44
  • 369
  • 561
  • 3
    Hibernate may also not be a good choice if other applications also update the database - in this scenario, you will at the very least need to make sure that Hibernate's second-level cache is not enabled. Also, even if you have a 'solid object model', if it's very different from the usual hibernate schema patterns, you may find data access to be very inefficient. – GreyBeardedGeek Jan 09 '13 at 01:59
  • 4
    And I'd also add that "solid object model" is highly subjective. I think hibernate/jpa forces you to do some things that are very anti-OOD. [I'll let Martin Fowler defend my controversial statement :)](http://martinfowler.com/bliki/AnemicDomainModel.html) (second to last paragraph) – Daniel Kaplan Jan 09 '13 at 02:13
  • I admire Martin Fowler very much, but I'll point out that this article is almost ten years old. Eric Evans DDD hasn't overrun the world. The phrase "procedural programming" sounds almost dirty. A lot of object-oriented patterns came about to address shortcomings that functional/procedural programming don't have. I don't agree that putting persistence in model objects is an anti-pattern. It's still an excellent comment. – duffymo Jan 09 '13 at 13:03
  • 1
    @duffymo procedural yes, functional no. A lot of OO patterns are just unnecessary in functional languages. – Rob Grant Jan 18 '17 at 10:33
4

I recommend looking at SansORM (a NoORM object mapper). It is designed for SQL-first development, which fits well with retrofitting an existing schema.

brettw
  • 10,664
  • 2
  • 42
  • 59
2

Hibernate works well if you can model your database under your objects.
Vice versa, you are likely to get the database model as your your domain model. You need to evaluate how distant those two models are, otherwise you are going to map the database => ORM objects => your domain model. I would avoid that.

If I want to skip the ORM part, I find myself quite happy with JDBI which I prefer over Spring JDBC Template

Luigi R. Viggiano
  • 8,659
  • 7
  • 53
  • 66
  • JDBI may be a good solution in isolation, but since OP is going to be using Spring anyway, Spring JDBC Template is a more likely choice in this situation. – GreyBeardedGeek Jan 09 '13 at 02:05
  • They are very similar, but I like how fluent API are implemented in JDBI. This is also an interesting experiment http://iciql.com/ – Luigi R. Viggiano Jan 09 '13 at 02:11
1

As others have pointed out an ORM is only a good choice if your database is not far from an object model.

If that is the case then an option would be Hibernate through JPA for two resons:

  • Netbeans has a tool to generate JPA Entities from an existing database. This entities are not dependant on Netbeans so you could use a different IDE after the initial reverse engineering.

  • Spring Data JPA can avoid writing trivial queries and focus on the hard ones.

madth3
  • 7,275
  • 12
  • 50
  • 74