Andrus Adamchik wrote:
> In 1.2 client-side objects are almost POJO already. Persistent interface is so simple that having a framework superclass is no longer a necessity, and I think I'll trim down "Persistent" even further... or get rid of it
> all together. So things may change.
This is one of those few moments where my Hibernate background can
finally come in useful. As you well know, Hibernate revolves around POJO
objects. Everyone seems to think this is a good thing, except me :) POJO
objects, in theory, sound great. The problem is that with transparency
you lose flexibility. Database rows are not really Java objects and when
you pretend they are you end up with a lot of abstraction leaks.
For example, when I invoke getFooArray() to get at a relationship, I
might want to tweak the performance by declaring the page size, fetch
limit, etc. So my point is this... feel free to move toward POJO but
please ensure that it is still possible to tweak these performance
settings on such "transparent queries". Hibernate's weakness is that it
is not possible to use transparent attributes/relationships while
tweaking their query settings.
Also ... if you use it long enough you find out that you *still* need
to wrap their so-called POJOs with a second level of objects. Hibernate
forces you to expose many DB-specific operations (setters mostly) that
end-users should not have access to. So either way you end up wrapping
your first DB-access objects with a 2nd layer of user-accessible
classes. That's why I prefer Cayenne. There is no disillusion about what
DataObject is. It's meant to be a DB object with full accessibility to
all its settings and wrapping it up in a 2nd level object is fairly easy
to do. No frustration there.
> *** Broken Example:
>
> Artist a = new Artist();
> Painting p = new Painting();
> p.setArtist(a);
>
> // this will not register a Painting as Artist knows nothing about it..
> context.registerNewObject(a);
>
> I can't think of a solution beyond class generation ... it would suck
> though. Or force users to register ALL objects they might have created.
> Not to transparent either.
Can you not encode the relationship logic statically into
p.setArtist(a)? Meaning, the implementation of p.setArtist(a) also
includes invoking a.addToPaintings(p)... I don't know if this is what
you were referring to when you talked about class generation. It's a
trade off. The relationships are bound at class-generation time (so I
think we lose some flexiblity there) but the benefit is that you don't
need a link to a ObjEntity to apply reverse relationships. You also gain
a lot in terms of being able to operate on unregistered objects almost
the same way as on registered ones.
Gili
This archive was generated by hypermail 2.0.0 : Thu Sep 08 2005 - 23:53:32 EDT