Recently i have been designing DAO classes for my application, I realized though the pattern abstracts the underlying SQL communication thru (CRUD methods )it does not provides more flexibility in usage. There can be N number of criteria for selecting or updating or deleting a record based on some condition, so condition will range in many numbers depending on the application so my question is should the DAOImpl class have that many methods, If not how is it effectively addressed in design
Nawaz Ahmed R
- DAO Pattern by Andy Grove on March 24 2004 12:07 EST
- DAO Pattern by Sean Sullivan on March 24 2004 13:15 EST
- DAO Pattern by Prasanna Kumar on March 25 2004 02:52 EST
- DAO Pattern by Jimmy Wong on March 25 2004 23:43 EST
- DAO-VO, CMP and BMP pattern by Vikram Waikar on March 26 2004 10:05 EST
You may find this information useful regarding capabilities of DAO:
DAO is a good design pattern. But performance wise CMP is more suitable for updating DB. You should use DAO for data base read like listing all customers ets. Reading huge number of records is not advisable through CMP.
DAO is a good design pattern.Really? My experience is that the DOA makes for tight coupling of your object with the persistence. I've been called upon to maintain systems that used DOA's. And those systems where significantly harder to maintain than those with an other form of persistence.
It just seems to me that patterns like Proxy or DataMapper are both more generic and easier to maintain. Anyone have other experiences?
I have used JDO to implement the DAO access code.
I found that if the DAO enscapsulate JTA Connection
(PersistenceManager), the performance of the DAO
is not acceptable since each call to the DAO needs
to make connection. Instead, I have created an interface
DAOConnection to wrap whatever underlying connection
type (e.g. java.sql.Connection, javax.jdo.PersistenceManager)
and ask the DAO to reuse the connection when performing update.
The performance of DAO using DAOConnection is 5times faster than
original DAO patterns.
The transaction demarcation is left to j2ee container in all cases.
DAO pattern is applicable to the data layer. VO pattern will be required along with it. DAO+VO combination is good , it is what we can call POJOs (Plain old java objects).
The alternatives to it are:
1. CMP bean
2. BMP bean
The criteria for selection can be:
1. Use CMP if
a. There are not too many relationships between DB tables
b. DB portability is of importance .. minimizing maintainability
2. Use BMP if
a. Scalability is of importance. Remember EJB container provides lots of features for this , e.g. bean pool, serialization support for excess beans
3. Use DAO+VO if
a. This will eliminate the need of a J2EE server. Plain web server like Tomcat will do. Good cost-cutting , if that is what you/company is looking for.
b. If scalability is not a concern, the anticipated load is not much.
If you need the flexibility of CMP , in DAO pattern , try using Factory pattern for the databases required to be supported.
DAO pattern is applicable to the data layer. VO pattern will be required along with it. DAO+VO combination is good , it is what we can call POJOs (Plain old java objects).The alternatives to it are:1. CMP bean 2. BMPDAO is a pattern for linking persistency in your model. CMP and BMP are ways of making an object persistent. The DAO object can be CMP, BMP or simple JDBC. The pattern does not specify how persistency is realized.
POJO's are indeed Plain old Java objects, by which it is meant that there are no links in the signature and behaviour towards specific frameworks. This is exactly why I would prefer implementations without the DAO pattern, because while the BO and the VO are usually POJO's the DAO is mostly not and even if the DAO is plain it often links to something that is not. And because the BO links to the DAO, that would mean the BO is not strictly speaking POJO.