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
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
0
