Discussions

J2EE patterns: Using Data Access Command Bean pattern with DTOs


  1. 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("XXX@XXX");
      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?
  2. Assuming that your original command interface had setters specified for email, name, etc, what you are suggesting is simply "collapsing" multiple sets on the command into a single set taking a "value object" of sorts, no?

    I mean the execute() implementation then will retrieve the inputs through your DTO object? Say I simply used a Hashtable instead of a DTO? I mean unless I missed something I'm not sure what the DTO is buying rather than putting restrictions on all command extensions. I say "restriction" very lightly here.

    IBM has a command framework that goes a step further. Not only does it define a TypedProperty class which is nothing but a glorified extension of a hash map. The command interface then specifies execute() which causes callbacks to implementation specified in the command extension such as checkParameters() for checking command input, performExecute() that actually carries out the command, etc.

    I have not read Floyd's book so am not sure how he has documented the exact pattern (yes, i have been a bad boy and did not review the pattern while it was available on the web site).

    In summary, I would say do whatever works for you. I would not apply any special rules to the documented pattern. I have always believed that the application of a pattern is as important as its definition. You don't have to "follow the book" in order to sacrifice maintenability, understandability or performance.
  3. The DTO has some tradeoffs vs. a HashMap but its trivial and really depends on the situation to make an arguement for one or the other.

    Your're right with the last paragraph. It looks like alot of these patterns can be mixed and matched with each other.
  4. why not change the setData method to
    setParameter(Object o)
    then the implementation of the abstract class can choose how to read it. then u have an abstract command pattern that u can use for anything, not only DTOBase objects.