You may also think of an alternative representation. Consider the objects used by clients as an "interface objects". A DAO objects then may be used as a truly "business objects".

The business objects may (and usually have to) be tightly coupled with database to communicate with it in a most efficient way. 

An interface objects, on the other hand, forms an API. An API has it's own requirements, which don't necessarily suit well with what DAO provides:

- A DAO object may expose the data, which should not be exposed to clients, such as passwords.
- A DAO data representation may differ from what client needs. For example, the same password field can be hashed in database, while the client code operates with a non-hashed variant.
- A DAO object may contain data not intended for direct manipulation by clients. Again, a password may be set during registration or checked for correctness, but not read.
- An interface objects may often have additional requirements applied by the framework they used by, such as JSF or RMI.