Hi 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.
..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.)
Piscis Babelis est parvus, flavus, et hiridicus, et est probabiliter insolitissima raritas in toto mundo.
Joined: Sep 20, 2003
Originally posted by Joel McNary: ..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.
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.