DAO Pattern Confusion

Question

Hello,
Have started developing with J2EE recently, moving up from J2SE. With regards to persistance of data to a database I have been looking at the DAO pattern. I am a little confused about this pattern, so I hope someone may be able to clear a few things up.
As I understand it the Transfer Object (TO) can be a simple java bean with getter and setter methods.
The DAO can only have four methods, create, read, update and delete. I am a little confused here, because as I see it, we can only have these four methods to read/write from/to the TO.
Isn't this very limiting? For example, the update statement of the DAO will have to have a TO which has already been populated, for this to occur an already populated TO has to be generated (a read on the DAO) and then the required values changed via the get/set methods of the TO. Then a method of the DAO has to be called to persist this data to the database.
This would cause difficulties if we wanted to implement optimistic locking for example, where we wanted to check if a row had been changed before commiting the change (to prevent lost updates).
Would it not be better to have many methods in the DAO, and a customer TO for each one? E.g. methods such as:
TO to = new TO();
to.setState("new");
to.setWhere("old");
dao.updateState(TO to)
Such a design would let us update the state of a row in the database to "new" where the state previously was "old" and hence be a basic implementation of optimistic locking.
Or are we completely missing the point!
Many thanks,

Answer 1

>>
IMO, this model is broken. TO's, as traditionally
implemented, are read-write. In most cases, it is
easier to code a TO as read-only. Provideinstance
values in the constructor and then expose onlygetter
methods. One possible implementation is to havethe
DAO and the TO (or preferably model object) in the
same package. Make the constructor of the TO
protected (or package private). Then, the DAO can
initialize values from the persistent store, but
users of the TO will only be able to read thevalues
retrieved. If this model becomes limiting, you
should realize that you are now allowing mutator
methods. IMO, your TO should now be afully-fledged
domain model object.
I disagree. And apparently others do as well because
your model is the way that J2EE first represented
DTOs (as a "Value Object").
I will refer you to Bloch, et. al. Immutable objects are easier to code and to test.
I suppose my reason for this would be that most of
the work in other layers involves sending mutated
data back. With your pattern this requires that the
user, every single time, create a new object, copy
the old data to the new, and then send the new object
back.
You are asserting the 'new' keyword is onerous?
Extra work with no gain.
I agree. There is an ever so slight overhead to creating a new, immutable object. However, limiting the possible states of an object, by definition, lowers its entropy and hence the possibilities one needs to test.
The DAO can only have four methods, create,read,
update and delete. I am a little confused here,
because as I see it, we can only have thesefour
methods to read/write from/to the TO.
This is roughly what a database allows. However,
what of commonly used parent-child or foreign-key
relationships? You may retrieve an account holder
and his/her present balance 90% of the time inyour
system. Do you want two separate TO's and DAO's
here? Or is this a case where a DAO can constructa
graph of objects in memory as an optimization?
Yes. Issuing a single SQL query to fetch a parent child relationship is more efficient than fetching foreign keys in a parent table and querying for each child. Maybe we are in fact on the same page, maybe not. But I am referring to releationships such as many-to-many that pose difficulties to O/R mappers. The same would hold true for a design where each table row corresponds to an object.
There are several other J2EE patterns for complex
relationships.
I am not sure I have ever encountered a need for
those though.
Other than chaining various Collection classes, neither have I. However, a fairly rich set of relationships (hierarchical, sequential, dependent, etc.) can be constructed from these.
>>
This would cause difficulties if we wanted to
implement optimistic locking for example, wherewe
wanted to check if a row had been changed before
commiting the change (to prevent lost updates).
I would not implement this myself. As Duffy has
alluded to, Hibernate and other O/R mapping
technologies maintain the state of an object andthe
state when it was retrieved, allowing theframework
to update only modified fields when needed.
Interesting.One of the best benefits that Hibernate offers out of the box, that and lazy loading. Though like all things, these too can be abused.
- Saish