Why do we need an Object Relational Mapper?

I bought a book on Hibernate. I wanted to learn on what Hibernate is and what is Object Relational Mapping in general.

Harnessing Hibernate has good topics on Hibernate and I do think that I am able to write simple mapping classes now. My problem is, I think I am way ahead on the Hibernate but I really don't know why we need one.

The book exp开发者_JS百科lains Hibernate clearly but I think I am at lost because it does not discuss why we need Hibernate and an ORM.

I too would suggest starting at wikipedia.

From there, follow the links at the bottom.

To provide a short answer: An ORM is used to abstract from the data storage, usually a database. This can serve multiple purposes, among those:

• Application programmers can add and maintain functionality of the software without in-depth knowledge of the database (you can write your code in Java, not in SQL).
• It takes away the pitfalls of having to assemble your SQL statements as strings and therefore eliminates a huge source of errors.
• Database optimization is independent from business logic. This ensures better maintainability. The optimization can either be done by the ORM ( via configuration files) or directly in the database (by manually adding index tables and/or query caches). Both will not take place in the actual program code.
• Data providers can more easily be exchanged, because the ORM usually offers drivers for multiple databases, so that the same functional logic will work with different products and vendors.

At its core, it's about Separation of Concerns.

Data persistence and logic are two separate concerns. The application coder should not have to concern himself with what flavor of SQL the IT staff has decided to use this week, and how to translate between the different paradigms of relation entities and object hierarchy entities.

The DBA should also not need to concern himself with object ownership rules and other almost-leaky concerns from the business layer.

In reality, in larger systems, you rarely can be completely vendor-agnostic, and the DAO layer inevitably picks up some non-ORM-related queries for performance tweaks. Tools like Hibernate do the best they can to make these situations as rare and abstract as possible.

Using an ORM like (N)Hibernate just makes sure that you don't have to worry much about writing SQL queries, it helps you focus on the 'domain' (business logic).

However, it is required to have some understanding of the underlying DB (and sql) in order to be able to create performant apps. :)

You might be writing a web-based application for a large company that could involve hundreds of thousands of objects of many different classes. You want to write all the business logic in object-oriented code, but these objects need persisting to an SQL database. Using ORM means you don't have to worry about how to convert to and from SQL, but can instead concentrate on implementing the actual application.

Wikipedia : Object Relational Mapping ? :)

To be more precise, an ORM allows you to use Objects directly bound to your Database.

For example, I have a Car, which has 4 object Door, each Door has a Color, each Color a Name.

With an ORM, I get my Car object from the Database. Then I go for a Car.GetDoors(), and I get a collection of my Doors, and for each one of them, I can use a Door.GetColor().GetColorName().

Which means that I didn't bother to write SQL queries to get the Doors from the Door Table, with a CarID, nor get a ColorName from the Color table with a colorID. An ORM thus allows me to write less code :)

Check this ! hibernate-interview-questions-faqs