If I use Cayenne to do the ORM, then it needs to have an integration
point to the model its trying to implement. Cayenne uses class
extension... all data objects must extend CayenneDataObject, so if
the model is interfaces I can create pojos that work in the ORM and
are usable in the services. If they are classes, I cant.
I could use the pojos, and copy into them from the orm, but that
would increase the volume of objects going through the JVM GC cycles
and could eliminate potential optimizations (lazy load, caching,
transactional caching in the orm)
I could use another ORM that just uses Pojos, like hibernate, but
that can be nasty since most of them generate really nasty SQL, and I
have some bad experiences.
or I could use JDBC direct, but when I saw the size of the object, I
decided it would be quicker to use an ORM.
The reason for Cayenne, is it creates good quality SQL joins that
DBAs dont go wild at.
If the service layer is almost pure interface, then the implementor
is not bound and there is clean separation. (I am leaving all Enums
in the interface, just enough to stop it being a class).
I agree with you on the AbstractGadgetData, although I can cope with
that one.
I could probably work with pojos and , but I think I would have to
resort to GCLib.... which is nasty.
Ian
On 20 Apr 2008, at 18:15, Cassie wrote:
Well... interfaces seem a lot more complicated then just pojos. Why
would a
pojo need to be an interface to begin with?
As for the AbstractGadgetData thing we really really need to get
rid of that
class, so that's a little bit of a separate issue. Ideally we would
just use
a java->json->java library which takes in any java object, and does
not
require inheritance. What we have right now is a very good stop gap
solution.
So why do you need to change the default pojo implementation of a
pojo? Can
you simply extend Person.java to do what you need? Any details
would greatly
help us all make a good design decision together.
Thanks.
- Cassie
On Sun, Apr 20, 2008 at 4:39 PM, Ian Boston <[EMAIL PROTECTED]> wrote:
I guess this is really a question for Cassie....
How receptive would you be to extracting interfaces from the model
area to
enable other implementation schemes.
eg
all the classes in org.apache.shindig.opensocial.model become
interfaces
the sample container provides an set of implementations bound to the
interfaces.
AbstractGadgetData implements a GadgetData interface and that is
used where
AbstractGadgetData is used.
I can provide a patch...
Ian
