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.
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. Rishi
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. Cheers!
Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).
Joined: Dec 09, 2000
Well 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
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
Joined: Mar 17, 2000
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.
Joined: Mar 17, 2000
Arijit, 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.