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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: dao versus Entity EJB
 
Similar Threads
XADAtaSource issue
Transparent Cross-domain Integration
Stereotypes in class diagram ?
Architectural Evolution with Entity Beans
dao pattern