Re: Mapping POJOs

From: Dhanji R. Prasanna <>
Date: Fri, 13 Apr 2007 10:03:15 +1000

> > When you write POJO do you mean the application data object ? As a
> > counter example, we've been working on an example that uses
> > JPA where
> > the application data objects are in the form of JPA entites. The
> > classes that contain our annotations are separate and are
> > much closer
> > to controllers in the MVC sense.

This sounds like a perverted use of JPA. The POJO objects that are your
"model" are intended to be annotated with javax.persistence annotations so
that they can directly be mapped to the RDMBS layer. This is certainly how
hibernate and toplink work. I am not aware that JPA has altered that
philosophy in any way.

I think invoking JPA strengthens Jerome's push of annotating the model POJOs
directly. While it maybe *possible* to use JPA in annotating the
"controller" (resource) rather than the model (entity), it would be a far

Fwiw, I am with you (Marc) in that I'd like to annotate the Resource rather
than the entity in the majority of cases and allow the use of any object as
the entity (a JPA annotated one or JAX-B generated one for instance).

Now its certainly possible to mix
> > controller and model in the same class but generally speaking its
> > cleaner to keep the separation and a lot of our thinking has been
> > modeled around an MVC approach where the JSR 311 annotations
> > would be for controllers rather than model classes.
> IMHO, the MVC paradigm is different (with some similarities) to the REST
> paradigm. Instead of speaking of Controller and View, we should be
> speaking
> in terms of Resource and Representation.

This is a reasonable analog. The model of course plays the same role in both
(i.e. entity).

An EJB service will typically be exposed as a Resource while an EJB Entity
> (or a graph) will be mapped to Representations.
> 2) We should focus on supporting as many POJO design style as possible in
> our annotation-based API, such as EJBs, JAXB, db4o, etc.

I agree that these should be possible (and even common case endpoints), i.e.
produced or consumed entity types.