SUN's Value object pattern won't work with EJB 2.0?

[steinarc]

I've just studied the article on Value Objects at SUN's web site http://java.sun.com/blueprints/patterns/j2ee_patterns/value_object/index.html on the pattern of Value Objects, furthermore I've been following a lengthy discussion at theserverside.com on the same issue.

I am confused as to which technique on should use to implement this pattern. I.e. is it a dead end to let the entity bean extend the value object? According to several good people, in EJB 2.0 all the fields in the entity bean are declared as abstract and thus one can not extend from the value object any longer.

This is stated in the discussion at the serverside.com:

http://www.theserverside.com/patterns/thread.jsp?thread_id=79

So what is the best strategy for implementing Value Objects? Taking into consideration that you really want value objects of course, i.e. your web container and Jboss is running in different JVMs.

[minamoto]

>According to several good people, in EJB 2.0 all the fields in the entity bean are declared as abstract and thus one can not extend from the value object any longer.

I'm not sure what this means. For value objects in EJB 2.0 we can define classes as return values or parameters to methods in remote interfaces.

By the way, I wonder Dependent Value Class may be used for the value object pattern if DVC is a simple object without relationships.
DVC is described in the EJB spec 10.3.3.

I'm just reading 'Dependent Value Classes' section of the third edition of EJB book by Richard Moonson-Haefel(I bought every edition of this book). In this example, the class Name is a DVC:

public interface CustomerRemote extends javax.ejb.EJBObject {
public Name getName() throws RemoteException;
public void setName(Name name) throws RemoteException;
}

The book says "Dependent value classes are useful for packageing data and moving between and its remote clients." but also says "CMP 2.0 does not specify how dependent value classes are defined".

Yesterday I bought the JBossCMP WorkBook then I found JBossCMP supports dependent value classes. I don't like to serialize composite objects to a binary db field but JBoss handles this well. Mapping of persistent fields is defined in jbosscmp-jdbc.xml.

I'm new to EJB 2.0.
Correct me if I'm wrong.

Miki

[steinarc]

Perhaps I am not doing a good job of explaining the issue I am raising :-)

According to SUN's Value Object pattern one may implement value objects as follows in order to eliminate code duplication between the entity bean and the value object:

---------------- CUT HERE -------------------------
public class ContactVO implements java.io.Serializable {

// public members
public String firstName;
public String lastName;
public String address;

// default constructor
public ContactVO() {}

// constructor accepting all values
public ContactVO(String firstName,
String lastName, String address){
init(firstName, lastName, address);
}

// constructor to create a new VO based
// using an existing VO instance
public ContactVO(ContactVO contact) {
init (contact.firstName,
contact.lastName, contact.address);
}

// method to set all the values
public void init(String firstName,
String lastName, String address) {
this.firstName = firstName;
this.lastName = lastName;
this.address = address;
}

// create a new value object
public ContactVO getData() {
return new ContactVO(this);
}

}

The entity bean sample code relevant to this pattern strategy is shown below.


public class ContactEntity extends ContactVO implements javax.ejb.EntityBean {

…

// the client calls the getData method
// on the ContactEntity bean instance.
// getData() is inherited from the Value Object
// and returns the ContactVO value object

…

}

----------------- CUT HERE

The full article can be found at http://developer.java.sun.com/developer/restricted/patterns/ValueObject.html

The point here being that letting the entity bean inherit from the value object, eliminates code duplication,
but according to discussions on www.theserverside.com ( http://www.theserverside.com/patterns/thread.jsp?thread_id=79 )
this won't work when using EJB 2.0 because the class is abstract and so is the getters and setters.

Henceforth, when using JBoss 2.4.x which is only EJB 1.1 compliant, letting the entity class inherit from the value
object works fine, but when migrating to a EJB 2.0 compliant server, it won't work any longer.

What I'm looking for is a method of implementing value objects without having to maintain the getters and
setters for the various fields in more than one place, which certainly is the case with Monson-Haefels book (3rd. revision) examples
on pages 168-170.

By the way, I have been looking for a work book related to JBoss, where did you find it?

[johnnycannuk]

Well, This is probably the case for CMP beans but for BMP(only CMP requires the abstract class and methods i think), I belive you can still do this under ejb 2.0. Another alternative we have tried on our project is composition rather than inheritance for this kind of bean ( currently for our ejb 1.1 project we have all our entity beans inherit from Value or 'state' objects - these same objects act as our data-transfer objects from the remote clients and the parameter of the create()).

It would work something like this:

public class TheBean implements javax.ejb.EntityBean {

...
...
private TheStateObject state;
..
..
}

instead of

public class TheBean extends TheStateObject implements javax.ejb.EntityBean {

}

Your create methods would look like

public The ejbCreate(TheStateObject theState) throws RemoteException{...}

and in the implementation you would set the private TheStateObject instance to the instance you are passing in and all your bean getters and setters or what have you would delegate to it.

I don't know if this helps at all....

[alu1344]

The pattern is not applicable for CMP beans since EJB 2.0 AFAIK :)

Maybe there is an option for not programming your Value Objects by hand implementing a task for XDoclet. I have not started to use XDoclet yet, but I can tell you it's possible because the local/remote/home interfaces are generated this way.

This way you could avoid implementing duplicate code, but the code would still exist :/

[dsundstrom]

Most of the EJB 1.1 patterns don't apply to EJB 2.0. These patterns were developed to address problems in the EJB 1.1 spec, so they all need to be reconsidered.

[cjohan]

I found another reason not to use the "Entity Inherits Value Object" strategy. It can cause some type checking to fail. For example, one can use an interface to specify the getter/setter methods that will enforce type checking in the entity bean and will cause the compiler to warn about missing or mangled getter/setter functions in the entity bean.
=================
public interface RegionIF {
public Integer getId() throws RemoteException;
public String getName() throws RemoteException;
public void setName(String name) throws RemoteException;
}

public class RegionEntity implements javax.ejb.EntityBean, RegionIF {
protected EntityContext context;
protected RegionData data;
protected RegionDAO dao;
protected boolean needWrite;
protected Logger logger;
...
// Getter/setter methods.
public String getName() {
return data.getName();
}

public void setName(String name) {
data.setName(name);
this.needWrite = true;
}

public Integer getId() {
return data.getId();
}
...
}
=================
However, if one inherits rather than delegates to the value object (RegionData in this case), then the type checking stops working since the RegionIF interface finds the inherited value object's getter/setter methods and thinks everything is OK no matter what getter/setter methods you provide in the entity bean.

In this code example, the entity bean keeps track of dirty data, so it needs its own setter methods that set the needWrite flag and forward to the value object.

[mkotsbak]

Xdoclet creates the Value Objects for you, and thus eliminate code duplication. You can also customize it with the merge-function.

It also has special support for value objects with aggregated associations.

Marius

[vincent]

I am currently reviewing the current data object of xdoclet to let the user specifies multiple ones per entity beans, let it define which fields belongs to which view (data, value, view all have the same meaning)
Aggregation or composition is now possible (Customer/Address or Order/Customer).
Now You can also add "computized" methods that runs on the entity and store the value on the view (e.g. getTotal() on Order)
As you mention, xdoclet is the perfect place to do this : continuous integration....
Linking the view and entity by subclassing is very poor imho.
It is in cvs now, I really need external eyes to validate the stuff.
I am moving to 1-n relationships as well.
It will generate the addLine(LineData) in Order, etc...
You want this one on th interface, you declare it asbtract and add ejb:interface-method.
You want setOrder(OrderView) to add/remove/update Lines, you will have that as well.
One week or two and it will be really nice. I am having a big fun doing that :)
With xdoclet gui on which others are hardly working, developping entity beans will become as easy as developping VB ;)

On the other hand, exchanging "view" between entity beans and its clients can also be done using xml, Hashtable, ...
I always prefered the Data/Value/View stuff because I find it more easy to add in it syntaxic validation to avoid touching ejb tier too often. I would like to hear others opinions here.

Regards.

[trajano]

I was wondering if the Value Object (aka. Transfer object) design pattern is still useful when we are using local interfaces instead of remote interfaces.

I am thinking its not too useful because

* the purpose of it was to remove serialization costs and network overhead. Local Interfaces already remove that cost.

* the entity beans are natural caches already so we do not have to create instances of this pattern and write our own caching code.