I read a lot of books that advise not use value objects between service tier( session beans ) and domain tier (entity beans). And so far I see in PetStore 1.3 the following :

public abstract class PurchaseOrderEJB implements EntityBean {
   ...
   public String ejbCreate(PurchaseOrder vo) {
        setPoId(vo.getOrderId());
        setPoUserId(vo.getUserId());
        ...

        return null;
   }
   ...
}
   Before EJB 2.0 spec we must have accept this pattern.
At this moment an only reason is to simplify changing of a local and component interface when it necessary to add new parameters.

  So I think it might be better to make as follows :

public class PetStoreSessionFacade implements SessionBean {
   ...
   public void createPurchaseOrder(PurchaseOrder vo) {
     PurchaseOrderLocal poLocal =
           getPurchaseOrderLocalHome().create(
                  Long primaryKey, some foreign keys );

     poLocal.setPoId(vo.getOrderId());
     poLocal.setPoUserId(vo.getUserId());
     ...
   }
   ...
}

 The createPurchaseOrder method is executed in one transaction so a good container's implementation should use one INSERT operator.
This way provides the following advantages :
  - different team can use different versions of value object assembler;
  - entity beans don't depend on an implementation of value objects ( data transfer objects );

   I'd like to get some comments about it.

Thanks in advance,
Alex

Yeah, i am agree with you.
But theory behind Data Transfer Object is to minimize network call. Anyway, it will minimize cration data class so in turn advantage in terms of reducing complexity.

I can't see any obstacles of using this particular pattern here. However, I don't see any reasons of introducing another loose coupling here - the main purpose of VOs is to participate in tight coupling, so I don't observe any logics here.

And you can't depend on a "good container's" CMP engine... From a container developer's point of view, I think that the first (old) approach would be more obvious to implement in one statement, than the latest one.

Alex

Hi!

In the proposed pattern, I can see two locations for complete data validation:
- In the constructor of the VO.
- In the setters in the EntityBean (using the setXyzField pattern to allow extra code on to of the abstract setters in CMP 2.0).

Since you don't want duplication of data validation code, you should implement this in a consequent way within the same project. Data validation in many locations is definitely an enemy in distributed computing!

/Tomas