Cassie,
Thanks :)
Still working on the DB code, but it would be good to know from
anyone else implementing in this area if the interfaces are the
right approach (and help)
Ian
On 21 Apr 2008, at 13:22, Cassie wrote:
Ah, okay, I understand now. *sigh* I guess we will need to do it, huh?
Oh well, I suppose its only 2 classes vs 1, not too bad.
I see your bug and will take a look at the patch soon.
- Cassie
On Sun, Apr 20, 2008 at 7:54 PM, Ian Boston <[EMAIL PROTECTED]> wrote:
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
