The Middleware Company is offering a free article pdf for download that discusses the popular J2EE Design Pattern known as the Data Access Object Pattern. The article is useful for people who may not have time to read a whole book, but may be interested in learning about a snippet of knowledge as they find the time.

You can download "J2EE Data Access Objects" at:
http://www.middleware-company.com/offer/8aug-a1.shtml

The link after the form is hanging my browser !

both IE and Netscape.

Please try again! It works both in IE and Mozilla.

Yup, download is NOT working
(hungs after forms, exacly as described above).
Windows XP, IE 6.0.26

Try right click and "Save Target As..." and save PDF locally.

Hope that helps!

Thanks,
Neven

I don't have any problem with downloading the document.

cheers,
- Rob

Me neither

Perhaps you should _upgrade_ to Mozilla :)

Don

try your download manager:

http://www.middleware-company.com/documents/DAOPattern.pdf

I don't get it!

In general, I would the article consider to be helpful. But there are two issues, that I'd like to discuss, because of my own experience, they can be solved better.

The first issue regards the DTO. While these objects are commonly known as value objects (this is mentioned in the article), I see no need in creating a new name for an old subject. Using a commonly used terminology decreases communication problems, and these problems happen often in IT projects.
But I don't want to stick with trivials. More important to me seems another part in the DTO pattern. The article implies to implement a JavaBean pattern like structure with getter and setter methods. This pattern is considered to be expensive, because these methods will not contain any logic but simple assignments. The better way in solving a DTO (or VO) pattern is to use public fields:

public class Item {
    public String name;
    public int count;
    public float cost;

    public Item() {}

    public Item(String name, int count, float cost) {
        this.name = name;
        this.count = count;
        this.cost = cost;
    }
}

This structure will provide more effective access to the DTO's fields and increase the readability of the code...

The second issue is the impelemntation of the DAO. The article proposes to implement an interface / implementing class structure. The implementing class will be used hard-coded in the source:

InventoryDAO dao = new JDBCInventoryDAO();

The problem is, that in the case of a new application server or an other database, the implementing class has to be changed everywhere in the code. I would suggest an other approach: The interface should be implemented as an abstract class, which is implements the abstract factory pattern:

public abstract class InventoryDAO {

    public abstract Collection getAllItems() throws DataAccessException;

    public abstract void addItem(Item i) throws DataAccessException;

    public abstract void removeItem(Item i) throws DataAccessException;

    public static InventoryDAO getInstance() {
        return new JDBCInventoryDAO();
    }

}

This can be improved, by using property files to set the class of the implementing InventoryDAO, which can then be instantiated dynamically:

(myApp.properties):

class.inventorydao = com.test.JDBCInventoryDAO


(InventoryDAO.java):

public static InventoryDAO getInstance() {
    try {
        return (InventoryDAO) Class.forName(resourceBundle.getString("class.inventorydao")).newInstance();
    } catch (Exception e) {
         e.printStackTrace();
    }

Any suggestions will be appreciated.

I would encourage people looking at this pattern to consider using JDO as an alternative to DAO. In a sense, JDO provides an automated way of generating the DAO layer and thus provides the same benefits. However with JDO, modification of the application or the data source is less time consuming than using DAOs because a tool is used to (re)generate the persistence code. Of course, this is a rather large over-simplification: JDO provides many additional benefits as well.

A good example of the "JDO pattern" is now available at IBM developerWorks:
http://www-105.ibm.com/developerworks/education.nsf/java-onlinecourse-bytitle/8CE3AB0807C9FA5786256BE200692408?OpenDocument

Richard Davies
LIBeLIS
http://www.libelis.com

Quote: "JDO provides an automated way of generating the DAO layer and thus provides the same benefits....a tool is used to (re)generate the persistence code"

<harsh-semi-biased-opinion>

Generated code is generally bad and does not scale. It also shows a lack of robustness in the framework. It also screams of highly repetetive code (even if it is generated). JDO is intrusive and bulky. JDO is a nightmare with no future.

</harsh-semi-biased-opinion>

Hey, it's just my opinion. ;-)

Cheers,

Clinton
www.ibatis.com

Scenario : User table contains 3 fields - UserID, UserName, UserAddress.
If I want to use the DAO pattern to create a new user then I would need UserBusinessObject, User(value object), UserDAO. Here's the code snippet:

public class UserBusinessObject {
   public addUser(String userName, String userAddress) {
      User user = new User();
      user.setUserAddress(userAddress);
      user.setUserName(userName);
      new UserDAO().create(user);
    }
    .....
}

public class User {
    //getters & setters for userName & userAddress
}

public class UserDAO {
   public User create(String userName, String userAddress) {
      //generate UserID
      //apply SQL to insert values into these 3 fields
      return new User(userID, userName, userAddress);
   }
   ....
}

As you see, I'm creating the User value object in the business object even though I do not have the userID. So basically the user value object is not really valid at this point! Is my assumption/implementation correct or wrong?

Thanks,

Poorav

Hi !
You created a new User object passing three parameters (in last after inserting values in DB),
first is UserId but where do you have method in User class to accept this?
Prasun

Moritz says:

'The article implies to implement a JavaBean pattern like structure with getter and setter methods. This pattern is considered to be expensive, because these methods will not contain any logic but simple assignments. The better way in solving a DTO (or VO) pattern is to use public fields'

No. Never use public member variables. Ever.

It goes against every principle of object oriented development/programming.

Jonathan

Jonathan,

your statement

"No. Never use public member variables. Ever.

It goes against every principle of object oriented development/programming. "

is absolutely right. But as long as the objects act as data containers only, it is not neccessary to implement methods. consider the overhead, if you have to rmi the objects for example.

Moritz.

Moritz:

Your statement on public fields: "But as long as the objects act as data containers only, it is not neccessary to implement methods. consider the overhead, if you have to rmi the objects for example."

The argument breaks down when you say: "as long as the objects act as data containers only". How can you ever guarantee that they will remain data containers? I have yet to see an application where this is true for the duration of the application lifetime.

In other languages that support true properties (Delphi, C#), this is not as important (IMHO) because you can always implement the property with a getter and setter later. However, with Java (or more specifically JavaBeans) you get only one chance. Then your only hope is some refactoring tool that provides an "encapsulate field" refactoring. But that's no fun at all when you have hundreds of business classes and possibly thousands of methods.

Cheers,

Clinton Begin
www.ibatis.com

What is the better solution.

1.Use a BMP EJB and within the BMP delegatecalls to the DAO.

2. Use the DAO directly from a session EJB.

3. Other??

I have been using approach 1. to gain the benifits of relationship mapping with other entity (CMP) EJBs

Thanks for any feedback.

Why do they ask for my email address? I'm getting tired of companies who give away a little sample just to scam emails. But of course no one gives their real email so what's the point??

http://jinx.swiki.net/282

http://daoexamples.sourceforge.net/

http://wiki.java.net/bin/view/Javapedia/DataAccessObject