In floyd's ejb design pattern book, he covers data access command beans as one of the patterns to deal with decoupling the logic/persistence details away from the ejb logic.
In the sample code, the following listing appears: (keep in mind that the InsertEmpCommand inherits from a DataAccessCommand base class)
<code>
InsertEmpCommand cmd = null;
try
{
  cmd = new InsertEmpCommand();
  cmd.setEmail("[email protected]");
  cmd.setName("DN");
  cmd.setID(id);
  cmd.execute();
}
catch (DataCommandException e)
{...}
</code>

now looking at this, it just makes absolute sense to take this decoupling one step further and use a DTO that extends from a base class that the data access command base would support a setter on.

example
<code>
public abstract class DataAccessCommand
{
  ...
  public abstract void execute() throws DataCommandException;
 
public abstract void setData(DTOBase dto);
...
}
</code>

this will then reduce the first code snippet to: (EmpDTO would extend DTOBase)

<code>
InsertEmpCommand cmd = null;
try
{
  cmd = new InsertEmpCommand();
  cmd.setData(empDTO);
  cmd.execute();
}
catch (DataCommandException e)
{...}
</code>

thoughts?

I'll move this message to the patterns section - this is more of a design patterns discussion than just an ejb design.