DAO Pattern

Discussions

EJB design: DAO Pattern

  1. DAO Pattern (7 messages)

    Hi All,

    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

    Regards
    Nawaz Ahmed R

    Threaded Messages (7)

  2. DAO Pattern[ Go to top ]

    You may find this information useful regarding capabilities of DAO:

    http://www.codefutures.com/products/firestorm/benefits/
  3. DAO Pattern[ Go to top ]

    http://daoexamples.sourceforge.net/
  4. DAO Pattern[ Go to top ]

    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.

    Prasanna Kumar
  5. Is DAO really a good pattern?[ Go to top ]

    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?

    Ralf
  6. DAO Pattern[ Go to top ]

    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.
  7. DAO-VO, CMP and BMP pattern[ Go to top ]

    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.
  8. DAO-VO, CMP and BMP pattern[ Go to top ]

    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
    DAO 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.

    Ralf