aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes dao versus Entity EJB Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "dao versus Entity EJB" Watch "dao versus Entity EJB" New topic
Author

dao versus Entity EJB

roul ravashimka
Ranch Hand

Joined: Mar 16, 2004
Posts: 53
Hi all,
suppose we have 3 different databases: a Pointbase, an Oracle and MS SQL server.
We could work in 2 ways:
1) DAO
We've got 1 DAO which talks(create, read, update, delete or CRUD) to the 3 databases at once. All the CRUD-code would be implemented at one place.
2) Entity EJB
We could write 3 Entity EJB's: one for each database. If we want to talk to the databases, we would have to lookup 3 Entity EJB and do the create, read, ... by calling methods on the Entity EJB's.
I suppose that the second way has got a lot of overhead. It would be better to work with one DAO.
Is this a correct point of view, or does someone can state way we should use the second(Entity EJB) way?
Greetings
Roul


MSc Electronics, ICT
Malli Raman
Ranch Hand

Joined: Nov 07, 2001
Posts: 312
Originally posted by Roul Ravashimka:
Hi all,
suppose we have 3 different databases: a Pointbase, an Oracle and MS SQL server.
We could work in 2 ways:
1) DAO
We've got 1 DAO which talks(create, read, update, delete or CRUD) to the 3 databases at once. All the CRUD-code would be implemented at one place.
2) Entity EJB
We could write 3 Entity EJB's: one for each database. If we want to talk to the databases, we would have to lookup 3 Entity EJB and do the create, read, ... by calling methods on the Entity EJB's.
I suppose that the second way has got a lot of overhead. It would be better to work with one DAO.
Is this a correct point of view, or does someone can state way we should use the second(Entity EJB) way?
Greetings
Roul

Hi Roul,
For point 1. you can define a interface, which contains the method signatures independent to the database. Then you can implement these methods in the database specific classes. During the runtime you can decide/create the database specific object. i.e you can use Factory method /Abstract Factory pattern.
For Point 2. I am not sure whether you have to use 3 Entity Beans which may affect the performance. I feel EJB's support all databases and only think you have to provide is the INITIAL CONTEXT FACTORY and URL PROVIDER Name in the properties file.
Regards,
M.S.Raman
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: dao versus Entity EJB