It's not a secret anymore!*
The moose likes EJB and other Java EE Technologies and the fly likes Entity Beans Vs JDBC Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Entity Beans Vs JDBC" Watch "Entity Beans Vs JDBC" New topic

Entity Beans Vs JDBC

Rishi Singh
Ranch Hand

Joined: Dec 09, 2000
Posts: 321
Hi All,
I would like to know whether to use Entity Bean or plain JDBC call to the database.How do we make a tradeoff when to use what.If plain java objects suffices, whether there is a need to use EJB
Juanjo Bazan
Ranch Hand

Joined: Feb 04, 2002
Posts: 231
If your application is very simple or just need a db connection to a single table maybe is not worth to use EJB.
But using entity bean interface gives you an persistent data object where you can encapsulate the logic of your bussines. With EJB you 'load your data in memory' maping your DB calls to different tables within the EJB.
All the underlaying dirty work as concurrency, lifecycle management and synchronize problems are provided then by the EJB.
Rishi Tyagi
Ranch Hand

Joined: Feb 14, 2002
Posts: 100
I am clearing it by simple example
1- suppose you want to validate a login in your program at this point only what you will have to do is make a simple query against the database. In this case a simple jdbc call will be a better solution but
2- suppose you are dealing with the transaction tables in an online shopping application then you may have to run more then 2 or 3 queries at the closing of the transaction or updation of the cart may be you will have to deal with 2 or more then 2 tables in this case now inspite of using the direct jdbc code in your client application it will be better to use an Enterprise Bean here as being a clinet programme developer it will prevent you from diving into the complexities of databse programming.
Ajith Kallambella

Joined: Mar 17, 2000
Posts: 5782
JDBC for reading is a highly recommended practice. If you can live with dirty reads( uncommitted reads ), you should not use EJB layer but go directly to the database.
However, if you need transactional capabilities, going through EJB layer saves you a lot of trouble. After all you have paid $$$ for that "famous" application server and why not use the facilities it provides instead of trying to cut corners?
One of the things you should consider early in your development cycle is the use of DAOs. If you encapsulate the logic to talk to the databse using JDBC in domain centric data acces objects, you can use the same code whether you use straight JDBC or entity beans layer. This architecture allows you to wrap an existing DAO inside an entity bean if the requirements change
during the course of the project or after it has been deployed. It is a very powerful and flexible design pattern.

Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).
Rishi Singh
Ranch Hand

Joined: Dec 09, 2000
Posts: 321
I can always use java.User.Transaction API to control the dirty reads/repeatable reads and phanthom reads by implementing database locking.
So the use of entity bean i.e( Objeact keeping
a database mapping) comes with lots of overhead and the very reason that I have invested in an EJB compliant app-server does not necessiates the use of Entity Bean.
EJB saves the developer from a lot of low level working but it comes with a cost...then if the same can be done with a litte effort with JDBC,Updatable ResultSets and Transaction Management with JTA why to use Entity Bean
Arijit Ghosh
Ranch Hand

Joined: Feb 01, 2002
Posts: 174
Hi Ajith,
w.r.t your reply.... Can you tell me that if I have a simple Java class with getter and setter methods... i.e. DAO then where should I package it ? With WAR file (containing Struts files ) or with JAR file (containing Bean class etc.. ) ?
Any examples that I can look up ?

Regards,<br /> Arijit
Ajith Kallambella

Joined: Mar 17, 2000
Posts: 5782
I am not contesting your opinion on entity beans. We both agree here that there is a cost involved in using entity beans and that JDBC offers perhaps a cheaper alternative. I agree you can use JTAs to implement transactional semantics without using entity beans.
Every project architect has to consider these issues in order to evaluate the relevance of proposed technologies and whether the additional costs introduced by such can be overweighed by the benefits. There is no silver bullet. However, when you buy-in yourself into using a technology, you should be aware of the limitations and how to overcome them.
Ajith Kallambella

Joined: Mar 17, 2000
Posts: 5782
DAOs usually go with the persistent layer and hence should be packaged with the JAR file containing the entity bean classes that use them. Think of a DAO as a value object plus JDBC logic. If you strip the JDBC logic, it becomes the good old VO.
VOs are usually aggregate objects and modelled after a client-interaction requirement. They are typically based on multiple domain objects. So, you should perhaps write another layer that consumes the DAO and generate a VO. It is perfectly legal to use the DAOs directly on the client if it makes sense.
This is just my opinion. I know there are several DAO patterns in use and I would love to hear what others has to say.
I agree. Here's the link:
subject: Entity Beans Vs JDBC
Similar Threads
�Session Beans vs Entity Beans�
Do you consider hibernate J2EE technology?
BMP using EJB3
POJOs vs. Entity EJBs