Tuesday, December 4, 2007

Hibernate: What is it, and why should I use it?

If you had asked me this question a few years ago, I would not have known how to answer it. I might have said, "Sure, isn't that what animals do in the winter time to conserve energy?!!!" ERRRRRRR, wrong! Well, it's partially correct. They do, but that is not what we are talking about here. It actually is also a great piece of software that I am not sure how prevalent it is inside the developer community. Hence, I will try to give you a quick intro to describe what hibernate is. Hibernate is an ORM, also known as an Object Relational Mapper. It maps database tables to Java or C# objects. You can use XML to map the elements of the table, or, if your using Java, the advancement of JPA (Java Persistence API) allows you to map the elements of the database table inside the class. That may be a lot to suck down so let me try to explain all of this with some sample code.

Here is a sample table from a database:
mysql> CREATE TABLE Car(
id INT,
data VARCHAR(100),
color VARCHAR(20),
engine VARCHAR(20),
type VARCHAR(20)
);
So now we have a table named car in a mysql database. Let's make a pojo using JPA, which makes use of Java annotations:

@Entity
@Table(name = "Car")
public class Car {
private Integer id;
private String data;
private String color;
private String engine;
private String type;

public Car () {
}

@Id
@Column(name = "id", unique = true, nullable = false)
@GeneratedValue(strategy = GenerationType.IDENTITY)
public Integer getId(){
return this.id;
}

public void setId(Integer id){
this.id = id;
}

@Column(name = "data", length = 100)
public String getData() {
return this.data;
}

public void setData(String data){
this.data= data;
}

@Column(name = "color", length = 20)
public String getColor() {
return this.color;
}

public void setData(String color){
this.color= color;
}

@Column(name = "engine", length = 20)
public String getEngine() {
return this.engine;
}

public void setEngine(String engine){
this.engine= engine;
}

@Column(name = "type", length = 20)
public String getType() {
return this.type;
}

public void setType(String type){
this.type= type;
}
}

Now we have a pojo that is mapped to a database table. This is the heart of the matter. So what good does this do for me? This leads us to question why should I use it.

Simply put, this is a very quick way to abstract a data layer for any project that needs access to a database. If you have a team of programmer's that have a limited knowledge of SQL, and mostly have knowledge of Java or C#, the results that hibernate will provide in productivity alone are worth it. Here are a few reasons off the top of my head that I have come up with:
  1. It is just not worth writing inefficient stored procedure's that your dev team will struggle with, that will ultimately have to be replaced later. Changes to these SP's could percolate all the way down to the business logic layer of your app. Definitely not good.

  2. An even worse solution if your team does not know about sp's would be to use inline SQL in code. This should be avoided at all cost unless you have only one or two tables and you don't really care about the application you are writing about. Inline SQL IS THAT BAD. Please avoid it to make your application easier to support. Support will love you for this! Not only that, new features will be easier to add, and database modifications will be easier to make since you have confined all of your logic to one layer.

  3. Hibernate is pretty easy to implement, check out the documentation and in about a day you will have a data layer you did not have to write from scratch. You can then focus more of your time on other equally important aspects of your application, like the business logic layer and the front end.
Things get more interesting when you start to relate tables and later on I will give you a more complete example. Hopefully I have explained what ORM's are and you can start digging in and checking out what these ORM's could offer you and your company in the future! Leave a comment and I will answer questions to the best of my ability.

Hope this helps!

3 comments:

Anonymous said...

Do these ORMs help in creating complex queries of multiple table joins or are they mostly for single table maintenance purposes?

Anonymous said...

In partial response to the question posed, there are built-in options to cascade queries. So say you have an user-defined object that contains a data member that is also an user-defined object. Then if each of these two objects is associated with a table in the database, creating a query on the owning object will draw data from both tables. Not a complete answer but enough of one to show that ORMs can do more than just update a single table at a time.

MatthewJ said...

GDI JL has it right. You don't have to worry about creating complex queries. This is inherent in the design of hibernate. Hibernate will do all the joins for you and persist all of your objects for you, by translating your object code to sql. I will provide a complete example of using Hibernate shortly when I get my computer setup in Conneticut. Hopeufully then you can see what hibernate does through the power of an example.