Here is a sample table from a database:
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:mysql> CREATE TABLE Car(
id INT,
data VARCHAR(100),
color VARCHAR(20),
engine VARCHAR(20),
type VARCHAR(20)
);
@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:
- 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.
- 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.
- 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.
Hope this helps!
3 comments:
Do these ORMs help in creating complex queries of multiple table joins or are they mostly for single table maintenance purposes?
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.
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.
Post a Comment