When to use Hibernate/JPA/Toplink?

Question

Right now I\'m making an extremely simple website- about 5 pages. Question is if it\'s overkill and worth the time to integrate some sort of database mapping solution or if it w

Answer 1

The best way to learn ORM is on a small project. Start on this project.

Once you get the hang of it, you'll use ORM for everything.

There's nothing too small for ORM. After your first couple of projects, you'll find that you can't work any other way. The ORM mapping generally makes more sense than almost any other way of working.

Answer 2

Do you mean plain old JDBC? A small project might be a good opportunity to pick up one of the ORM frameworks, especially if you have the time.

Without more information it's hard to provide a recommendation one way or another however.

Answer 3

My rule of thumb is if it's read-only, I'm willing to do it in JDBC, although I prefer to use an empty Hibernate project with SQLQuery to take advantage of Hibernate's type mapping. Once I have to do writes, I go with Hibernate because it's so much easier to set a few attributes and then call save than to set each column individually. And when you have to start optimizing to avoid updates on unchanged objects, you're way better off with an OR/M and its dirty checking. Dealing with foreign key relationships is another sign that you need to map it once and then use the getters. The same logic would apply to Toplink, although unless they've added something like HQL in the 3 years since I used it, Hibernate would be much better for this kind of transition from pure SQL. Keep in mind that you don't have to map every object/table, just the ones where there's a clear advantage. In my experience, most projects that don't use an existing OR/M end up building a new one, which is a bad idea.

Answer 4

Look at the various toplink guides here, they have intro, examples, scenarios etc

http://docs.oracle.com/cd/E14571_01/web.1111/b32441/toc.htm

Answer 5

It does seem like it would be overkill for a very simple application, especially if you don't have plans to expand on it ever. However, it also seems like it could be worthwhile to use those with this simple application so that you have a better understanding of how they work for next time you have something that could use them.

Answer 6

Short answer: It depends on the complexity you want to support.

Long answer:

First of all, ORM ( object relational mapping - database mapping as you call it - ) and JNDI ( Java Naming and Directory Interfaces ) are two different things.

The first as you already know, is used to map the Database tables to classes and objects. The second is to provide a lookup mechanism for resources, they may be DataSources, Ejb, Queues or others.

Maybe your mean "JDBC".

Now as for your question: If it is that simple may be it wouldn't be necessary to implement an ORM. The number tables would be around 5 - 10 at most, and the operations really simple, I guess.

Probably using plain JDBC would be enough.

If you use the DAO pattern you may change it later to support the ORM strategy if needed.

Like this: Say you have the Employee table

You create the Employee.java with all the fields of the DB by hand ( it should not take too long ) and a EmployeeDaO.java with methods like:

+findById( id ): Employee
+insert( Employee ) 
+update( Employee )
+delete( Employee ) 
+findAll():List<Employee>

And the implementation is quite straight forward:

select * from employee where id = ?
insert into employee ( bla, bla, bla ) values ( ? , ? , ? )
update etc. etc 

When ( and If ) your application becomes too complex you may change the DAO implementation . For instance in the "select" method you change the code to use the ORM object that performs the operation.

public Employee selectById( int id ) {
      // Commenting out the previous implementation...
      // String query = select * from employee where id = ? 
      // execute( query )  

      // Using the ORM solution

       Session session = getSession();
       Employee e = ( Employee ) session.get( Employee.clas, id );
       return e;
}

This is just an example, in real life you may let the abstact factory create the ORM DAO, but that is offtopic. The point is you may start simple and by using the desing patterns you may change the implementation later if needed.

Of course if you want to learn the technology you may start rigth away with even 1 table.

The choice of one or another ( ORM solution that is ) depend basically on the technology you're using. For instance for JBoss or other opensource products Hibernate is great. It is opensource, there's a lot of resources where to learn from. But if you're using something that already has Toplink ( like the oracle application server ) or if the base is already built on Toplink you should stay with that framework.

By the way, since Oracle bought BEA, they said they're replacing Kodo ( weblogic peresistence framework ) with toplink in the now called "Oracle Weblogic Application Server".

I leave you some resources where you can get more info about this:

---

In this "Patterns of Enterprise Application Architecture" book, Martin Fowler, explains where to use one or another, here is the catalog. Take a look at Data Source Architectural Patterns vs. Object-Relational Behavioral Patterns:

PEAA Catalog

---

DAO ( Data Access Object ) is part of the core J2EE patterns catalog:

The DAO pattern

---

This is a starter tutorial for Hibernate:

Hibernate

---

The official page of Toplink:

Toplink

---

Finally I "think" the good think of JPA is that you may change providers lately.

Start simple and then evolve.

I hope this helps.