in a session facade pattern when exactly to use dao and when to use entity bean(IN WHICH

CONTEXT).it's said that dao is used in order to make data acess independent of the medium whether
it uses dbms ,ldap or any legacy system.the same thing could be achived by using datasource
object(in dao object also uses datasource object for acessing ldap and legacy system)in entity
bean.iam beginner in dao please correct me if iam wrong.

First off, DAO is primarily relevant to BMP entity beans. You won't use a DAO with CMP
(since the server generates all your JDBC logic).

Secondly, you may want to do an end run around your entity beans and talk directly from
your session bean to the database. This is especially true for reading large datasets; EJB finder
methods have a lot of overhead. DAO makes this approach more flexible.

Normal: session -> entity -> database

High Performance Reads: session -> DAO -> database

Finally, an major advantage of DAO is that a properly written DAO can be tested (and used)
outside your EJB container. This means that you DAO logic is independant of EJBs entirely,
letting you reuse it in other situations (e.g. a standalone web app that does not use EJB).

It is rigth to say that U can It is justified to compare DAO with BMP entity beans.

A normal DAO just seperates all the database access codes into a different Object.DAOs are msotly
used when we are using on session beans for database access.What we will do is just put in all the
database related codes like querries into the DAO and access it when ever we need to access
database.

An entity bean mostly CMP lets the container implement all its database related codes and that way
allows the container to handle persistence,transactions and many other properties.

U caan very well use DAOs with BMP entity beans.

All this depends upon ur requirment and the design path U select.

DAO and CMP is an area I am struggling with as well. In your response you say you would
not use DAO with CMP. Should this always be the case?

Say for example that I am using CMP2 Entity Beans, but there is a particular business process
that requires READ access to many rows stored in numerous tables in the database. Should I
still use EJB finder methods to look-up this data or is it Ok to write a DAO object that can be
referenced by a session bean?
Another issue I have come up against with Entity Beans is that the finders are required at
design time. How do I implement a 'Query Builder' in the Enterprise Application. This is
relevant for an application I am working on at the moment, one of the requirements is a
Report Generator. I can generate SQL until the cows come home, but how do I squeeze this in
to the enterprise application?

I have assumed that using DAO for database Reads is Ok, even though I am using CMP
Entity Beans for all database writes. Is this incorrect?

We can not compare a Pattern (DAO) with a persistence technology Entity beans.
we can use a DAO pattern over entity beans , plain JDBC , hibernate , JDO , ...
So you use DAO to encapsulate Data Access in a seperate layer and make data access
independent of persistence technology and abstract the access to data from upper layers.

The purpose of DAO pattern is to uncouple the database logic from other work flow. Entity
beans are used for persistance. So both are different purposes.

..but you can use DAOs for persistence. After all, they are Data Access Objects. There's no
reason say they can't be used for persistence. At my comapany, we have two types of DAOs:
entity DAOs and custom DAOs. The entity DAOs handle persistence (and are generated
based on the database, so we don't have to hand code them), the custom ones handle whatever
they need to.

Personally, I stopped using entity beans years ago -- back around EJB v1.1. They were (and
still are) cumbersome and don't translate between application servers very well. My company
changed from entity EJBs to straight DAO because the Entity Bean model just didn't work
very well (performance was also an issue).

So, my recommendation is quite simple: don't use entity beans. There are a number of other
persistence mechanisms out there that cause fewer headaches (Hibernate, strainght DAO, etc.)

I did not mean we can not use DAOs for persistence. I mean to say that the purpose of DAOs
are to uncouple the database logic so that any changes in database related activities(like
change in database) will become simpler.

From Sun Blueprints:

Use a Data Access Object (DAO) to abstract and encapsulate all access to the data source.
The DAO manages the connection with the data source to obtain and store data.

Data Persistence: Top 5 Reasons to Use DAO Rather than Entity Beans

 DAOs scale across the enterprise and can be used with J2SE and J2EE (not true with
Entity Beans)
 DAOs are 100% portable between different J2EE application servers without
modification (not true with Entity Beans due to different deployment descriptors
 DAOs can be automatically unit tested from an automated build system without
deploying them to a J2EE application server
  DAOs support Tables (with or without primary keys), Views, and Stored Procedures
whereas Entity Beans only support Tables with primary keys
 DAOs are more suitable for distributed architectures than Entity Beans since Data
Transfer Objects can be passed between the client and server efficiently than remotely
calling get/set methods on an Entity Bean

FireStorm/DAO makes Java software developers more productive by automatically

generating Java source code for accessing databases. The benefits provided by CodeFutures'
Java code generation approach are higher developer productivity, better software quality, and
lower maintenance costs.

FireStorm/DAO can import database schema definitions from SQL scripts or from live
databases via JDBC and can then generate a complete persistence tier based on the Data
Access Object (DAO) design pattern. The generated source code is well-written, consistent
and contains documentation. FireStorm/DAO can generate source code based on the Java
Database Connectivity (JDBC), Java Data Object (JDO), and Enterprise JavaBean (EJB)
standards. FireStorm/DAO can generate code for standalone Java as well as for leading J2EE
application servers, such as JBoss, BEA WebLogic, IBM WebSphere.

Retrieving data by using Entity Bean finders loads all of the attributes for the entity, even
when you might only need the value of one of them for the task at hand. So, indeed, EJB
finders methods have overhead and this is especially true when retrieving large data sets (not
even to mention when you are invoking 15 of them).

So, to retrieve large read-only data sets, it may indeed be preferable to talk to the database
directly from the Session Bean (I guess that you have a Session Bean facade) using JDBC
API. This pattern is known as Fast Lane Reader if I remember well.

Just keep in mind that implementations of this pattern sacrifice data consistency for
performance, since queries performed at the raw JDBC level do not "see" pending changes
made to business information represented by Enterprise Beans.