In short, instead of keeping around the DTO, just keep around a key to get to that DTO, whether in a hidden field or the session. Then, you can call up the DTO at any point, update it and push it back to the persistence layer when you want to save it. The nice part about this technique is that your action forms and DTOs don't even have to align, since you draw what you need out of the form and push it into your DTO to be saved.
If you are using a coarsely-grained data access API, then this is certainly a useful strategy. Though, if you have a client story that calls for certain fields to be updated, then that story should be reflected in the data access API (or DAO). Especially, if you are counting trips to the databse. :)
A popular strategy is to use a Transfer Object to define the parameters that might be needed by a data access API, and then declare as many data access methods are needed. The Struts Mailreader uses this "Context and Command" design as does JPetstore3. That some of the fields were null wouldn't matter to these specialized methods. Generally speaking, I like to try and frame things around the client stories, right down to the data access layer.
-Ted.
-- Ted Husted, Junit in Action - <http://www.manning.com/massol/>, Struts in Action - <http://husted.com/struts/book.html>, JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
"Get Ready, We're Moving Out!!" - <http://www.clark04.com>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
