Hi Guys... I have one doubt. needs help from u ppl. Suppose there r 5-6 tables, so its certainly not a good idea to code as much number of Entity Beans. What i have read is, make one Entity Bean n then make others as DAO(Data Access Objects) and map the DAOs with the table. I don't understand how to do that..:-( could anyone of u plz explain it. On a high level i just want to know that how introduction of DAO reduces the number of Entity Beans??? I have read books(Design Patterens from wrox publication), i know wat DAO is, but unable to understand the logic which i have mentioned above. Any sample code will definitely be of gr8 help. Thanx in Advace. Jam
In a DAO you code your own SQL. There are no restrictions on the kind of SQL you can use. Therefore, you can use table joins (or Views, or other SQL constructs) that you can't use with CMP at all, or that you would use with difficulty in a BMP. So, a DAO could create a single object (a value object) from something like a 5-table join. That would be impossible with CMP. Likewise it could know how to pick apart the same value object and store its fields in all 5 tables. Kyle
hi, i dont think that the DAO goal is to reduce the number of entity beans. it's goal is to decouple the entity bean with the specific data storage implementaion(relation DB , or other DB). the way you need to reduce your entity beans is by designing the entity as a component that contains a joined data from number of tables. you can create a number of DAO's for each table and in the entity bean store and load methods work with the DAO's according to the changes made by the entity bean. that way it would make it more easier to write and maintain the persistence specific code (JDBC in your case).
Hi, Tx for the reply So it means that if i have lots of tables so the better idea is to have one Entity Bean, n make DAOs corresponding to other tables. join them together if possible in DAO, n then call the DAO in Entity Bean. Plz correct me if i m wrong Tx once again for ur help Jameel
Hi, What I m saying is, suppose there r 15-20 tables in a project, and the requirement is in such a way that we have to go for entity beans(BMP for example).So in that case, would it be right to code 15-20 entity beans for every table?? r the better idea would be use of DAO n map each dao with different table?? If we are going for DAO, then how do v use it??? This is my concern. Can I use DAO without making any entity bean n use them in Session beans? r make one entity bean n use DAOs in that entity bean?? Consider the following architecture-- JSP-->> Java Bean-->> Session Bean-->> Entity Bean-->> Data Base(Oracle) So keeping the above architecture in mind, when i want to use DAO, so in that case would it replace Entity Bean from the above architecture something like this?? JSP-->> Java Bean-->> Session Bean-->> DAOs-->> Data Base(Oracle) OR JSP-->> Java Bean-->> Session Bean-->> Entity Bean-->>DAOs-->> Data Base(Oracle)
Plz explain me which architecture will be correct when i m using DAO?? Thanx in Advance Jam
U use a DAO so that u can write complex queires with joins to multiple tables which cannot be achieved by using a CMP entity bean. In ur case, out of the 10-15 tables atleast a few will be master tables. For such tables u can go for CMP entity beans. For other tables which will have lots of foreign key references u can go for DAO. However if u are having BMP beans, it is a good practice to use a DAO which handles all the jdbc calls. That way, u won't have make changes to ur beans everytime u want to change a query. For a direct CMP bean that maps to a master table in the databse, the flow will be JSP-->> Java Bean-->> Session Bean-->> Entity Bean-->> For a BMP bean the flow will be, JSP-->> Java Bean-->> Session Bean-->> Entity Bean-->>DAO-->> Data Base(Oracle) If u want to skip using entity bean in such cases u can call the DAO directly from the session bean JSP-->> Java Bean-->> Session Bean-->>DAO-->> Data Base(Oracle)