| |
|
How to decide which persistence technology to use? JDBC / CMP Entity Beans / Hibernate / JDO ? |
|
|
|
Written by Harshad Oak
|
|
Dec 18, 2004 at 09:09 AM |
|
Page 1 of 4 Almost every web application today talks to a database and so at the start of each project, one question is surely going to come up. Which persistence technology to use?
I tried to google my way to the answer however either my google skills
are limited or the answer / a fair comparison of the available
technologies isn't out there.
So I thought of making this blog
interactive. You post comments to this blog and state what you think is
for or against a particular technology. I will later compile all
suggestions into a tabular form. Keep your comments short so that they
can easily be placed in a tabular format.
Lets restrict the scope of the comparison to:
- JDBC
- Hibernate
- CMP Entity Beans
- JDO
Java persistence technologies. A comparison.between JDBC, Hibernate, CMP Beans and JDO
| |
JDBC |
Hibernate |
CMP Beans |
JDO |
| Plus |
| 1 |
Everyone knows it |
Easy to learn |
Ease of use
|
Vendor portable |
| 2 |
Suited for small systems |
Good performance |
IDE support
|
Many vendors |
| 3 |
Performance |
JSR-220 (EJB3) persistence |
Resume booster |
Adopted by Apache |
| 4 |
Stored procedure usage |
Middlegen code generation |
Middlegen code generation |
Geronimo Integration |
| 5 |
Batch updates/inserts
|
|
|
JDO vendors will support EJB 3 as well |
| 6 |
|
|
|
Middlegen code generation |
| 7 |
|
|
|
great help from vendors |
| Minus |
| 1 |
|
Not backed by specification |
Heavy and complex
|
Low acceptance |
| 2 |
|
Have to learn on your own. Not enough help on forums |
Steep learning curve
|
Risky long term choice
|
| 3 |
|
|
|
Few credible vendors |
| 4 |
|
|
|
|
| 5 |
|
|
|
|
| Other comments and suggestions |
| 1 |
Prevayler (not listed) - Best if you are making a very small system (in terms of data size) that WILL NOT grow significantly and you dont' need a RDBMS. Very easy to learn. Pure OO. Fast development. Excellent performance. |
| 2 |
What about IBatis? |
| 3 |
Forget the specs go with the best tool for the job. And there are way more tools then just hibernate. |
| 4 |
I can't say use this or that. Each has it's advantages. Choose one and stick with it. |
| 5 |
In the Torpedo benchmark, the top 2 performers are JDO implementations, beating out TOPLink, Weblogic CMP, and Hibernate. |
| 6 |
Torpedo is a very useless benchmark. |
| |
|
Comment by Guest on 2004-12-20 17:18:13
-major vendors such as BEA and IBM voted against the JD0 2.0 specification
-Sun is promoting EJB 3.0 heavily and issued an open letter than mentions putting JDO into "maintenance"
|
Comment by Guest on 2004-12-20 17:23:20
I've found CMP trivial to implement but BMP has much more efficiency than BMP... I'd almost rather see BMP listed here than CMP, but then again, most developers probably will disdain the thought of BMP. |
Comment by Guest on 2004-12-20 17:35:30
No specification behind hibernate is a definite minus.
Developer familiarity with JDBC is a Plus +1 for JDBC. Most Java developers learn JDBC right after they learn Java. So most are pretty good at JDBC. |
Comment by Guest on 2004-12-20 17:52:45
Hibernate3 implements/will implement JSR-220 (EJB3) persistence, a major specification in the Java space with support from the big Java vendors. You can download preview releases (and Hibernate3 beta) from the JBoss/Hibernate websites.
|
Comment by Guest on 2004-12-20 21:07:09
- CMP/EJB - bleech. Too heavy. Only reason I'd use it would be to enhance my resume or get a job. Long learning curve. Complex development (XDoclet and IDE tools help). Performance may be an issue.
- JDO - Too limited. Not respected by many. Probably won't last as a standard. Easier than EJB. Unsure about performance; should be reasonable.
- Hibernate - Best choice for O/R mapping. Best choice in general, really. Not hard to learn. Reasonable performance.
- Prevayler (not listed) - Best if you are making a very small system (in terms of data size) that WILL NOT grow significantly and you dont' need a RDBMS. Very easy to learn. Pure OO. Fast development. Excellent performance.
- JDBC - Best if you need a RDBMS and are making a minimal system or a prototype. Difficult to apply good OOD. No learning curve (everyone knows it [or should]). Good performance.
|
Comment by Guest on 2004-12-21 02:39:25
The Public Final Draft of the JDO 2 specification was announced today (so much for it being a maintenance-only spec!). It is available now, and it has more features than EJB 3 persistence plans to have when it is finalized in 2006 (so much for JDO being "limited"). Apache just announced that it will host the JDO 2 API and TCK, and the open source JPOX project will host the reference implementation. JDO vendors (and there are many) are already offering many JDO 2 features in their products. In the Torpedo benchmark for ORM solutions created by TheServerSide.com, the top 2 performers are JDO implementations, beating out TOPLink, Weblogic CMP, and Hibernate. |
Comment by Guest on 2004-12-22 00:03:14
Torpedo is a very useless benchmar.Every good ORM implementation (and there are about 5 at the moment) will get the top score easily. If one of the products hasn't, its just because nobody really cares about another useless benchmark.
Torpedo only tests SQL generation for a handful of almost trivial cases (it improved significantly in the second version, but its still trivial), an area where ORM solutions are 99.99% perfect for more than a year. It's not testing any relevant load performance or any other important feature.
|
Comment by Guest on 2004-12-22 01:23:25
I can't say use this or that. Each has it's advantages. Choose one and stick with it.
I would prefer CMP, it's easy to use if you have an IDE supporting your Applicationserver (I use WSAD for Websphere Development).
If wouldn't have such tools, i think i'd use hibernate or jdo. jdbc is only an option if you want to optimize for performance. |
Comment by Guest on 2004-12-22 07:04:00
However, its not perfect.
I would never pick it to do batch processing. Its great for the web enviroment. However, I wish it had better ability to delegate an interceptor responsible for object deletion.
You might still find yourself writing sql/jdbc code.
In one of our systems, when we delete a task there is a bunch of stuff that needs to be cleaned up. If I were to make hibernate responsible(assoicate collections with cascade behavior) it would be way to slow in this case. |
Comment by Guest on 2004-12-22 11:59:44
Torpedo is a very useless benchmar.Every good ORM implementation (and there are about 5 at the moment) will get the top score easily.
Then why have only 2 ORM implementations gotten the top score? And why are the top 3 all JDO implementations? JDO's enhancement strategy allows for some optimizations that other strategies simply can't match.
That said, of course there's a lot more to ORM than Torpedo. But I think top JDO implementations like the one that TheServerSide uses to power its site (see TSS's "About" page) also compete extremely well on overall feature set and mapping flexibility. Combine that with JDO's vendor portability and the upcoming advances in JDO 2, and it makes for a compelling argument. |
<< Start < Previous 1 2 3 4 Next > End >>
|
|
|
|
Home | 
